Reconciliation of indirectly executed exchanges of data using permissioned distributed ledgers

ABSTRACT

The disclosed exemplary embodiments include computer-implemented systems, apparatuses, and processes that monitor and reconcile indirectly initiated exchanges of data between network-connected devices and computing systems using a permissioned distributed ledger. For example, an apparatus may obtain and transmit first transaction information characterizing a data exchange to a first computing system. The first computing system may submit a portion of the first transaction information to a second computing system through a programmatic interface inaccessible to the apparatus, and the second computing system may execute the data exchange in accordance with at least the portion of the first transaction information. The apparatus may also obtain at least one element of a distributed ledger that includes encrypted second transaction information characterizing the execution of the data exchange, decrypt the encrypted second transaction data and perform operations that reconcile the first transaction information and the decrypted second transaction information.

TECHNICAL FIELD

The disclosed embodiments generally relate to computer-implementedsystems and processes that reconcile indirectly executed exchanges ofdata using permissioned distributed ledgers.

BACKGROUND

Today, payment systems and related technologies continuously evolve inresponse to advances in payment instruments, such as the ongoingtransition from physical transaction cards to digital paymentinstruments maintained on mobile devices. These innovations result inadditional mechanisms for submitting payment to an electronic orphysical merchant and for flexibly funding transactions initiated by theelectronic or physical merchant. These innovations also result in agrowing variety of financial institutions and similar entities thatprocess payment transactions on behalf of both customers and merchants,and access existing payment rails and transaction processing networksindirectly through one or more direct participants.

SUMMARY

In some examples, an apparatus includes a communications interface, amemory storing instructions, and at least one processor coupled to thecommunications interface and the memory. The at least one processor isconfigured to execute the instructions to obtain first transactioninformation characterizing a data exchange and to transmit, via thecommunications interface, the first transaction information to a firstcomputing system. The first computing system is configured to submit aportion of the first transaction information to a second computingsystem through a programmatic interface, the second computing system isconfigured to execute the data exchange in accordance with at least theportion of the first transaction information, and the programmaticinterface is inaccessible to the apparatus. The at least one processoris further configured to execute the instructions to load at least oneelement of a distributed ledger from the memory. The at least oneelement includes encrypted second transaction information thatcharacterizes the execution of the data exchange by the second computingsystem. The at least one processor is further configured to execute theinstructions to decrypt the encrypted second transaction data andperform operations that reconcile the first transaction information andthe decrypted second transaction information.

In other examples, a computer-implemented method includes obtaining, byat least one processor, first transaction information characterizing adata exchange and transmitting, by the at least one processor, the firsttransaction information to a first computing system. The first computingsystem is configured to submit a portion of the first transactioninformation to a second computing system through a programmaticinterface, the second computing system is configured to execute the dataexchange in accordance with at least the portion of the firsttransaction information, and the programmatic interface is inaccessibleto the at least one processor. The computer-implemented method alsoincludes obtaining, by the at least one processor, at least one elementof a distributed ledger. The at least one element includes encryptedsecond transaction information that characterizes the execution of thedata exchange by the second computing system. The computer-implementedmethod further includes, by the at least one processor, decrypting theencrypted second transaction data and performing operations thatreconcile the first transaction information and the decrypted secondtransaction information.

Further, in some examples, an apparatus includes a communicationsinterface, a memory storing instructions, and at least one processorcoupled to the communications interface and the memory. The at least oneprocessor is configured to execute the instructions to receive, via thecommunications interface, first transaction information characterizing adata exchange from a first computing system. The data exchange isinitiated by a device in communication with the first computing system,and the at least one processor is further configured to transmit, viathe communications interface, a portion of the first transactioninformation to a second computing system through a programmaticinterface. The programmatic interface is inaccessible to the firstcomputing system, and the second computing system is configured toexecute the data exchange in accordance with at least the portion of thefirst transaction information. The at least one processor is furtherconfigured to generate second transaction information that characterizesthe execution of the data exchange by the second computing system,encrypt the second transaction information using a public cryptographickey of the first computing system, and transmit, via the communicationsinterface, a recordation request that includes the encrypted secondtransaction information to a peer computing system. The recordationrequest causes the peer computing system to perform operations thatrecord the encrypted second transaction information within an element ofa distributed ledger, the distributed ledger being accessible at thefirst computing system.

The details of one or more exemplary embodiments of the subject matterdescribed in this specification are set forth in the accompanyingdrawings and the description below. Other potential features, aspects,and advantages of the subject matter will become apparent from thedescription, the drawings, and the claims.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagram of an exemplary computing environment, consistentwith disclosed embodiments.

FIGS. 2A, 2B, 3A, 3B, 4, 5, 6A, and 6B illustrate portions of anexemplary computing environment, in accordance with the disclosedembodiments.

FIGS. 7-9 are flowcharts of exemplary processes for executing andreconciling cryptographically secure exchanges of data usingpermissioned distributed ledgers, in accordance with the disclosedembodiments.

Like reference numbers and designations in the various drawings indicatelike elements.

DETAILED DESCRIPTION

This specification relates to computer-implemented processes that, amongother things, monitor and reconcile a status of indirectly initiatedexchanges of data between network-connected devices and computingsystems using a permissioned distributed ledger. In some instances, oneor more of the computing systems may be associated with, maintained by,or operated by a financial institution that provides financial servicesto customers. As described herein, these provisioned financial servicescan include, but are not limited, a clearing and settlement of paymenttransactions based on elements of payment data submitted directly, orindirectly, to one or more transaction processing networks.

In some examples, a financial institution may represent a directparticipant in the one or more transaction processing networks, and as adirect participant, the financial institution may provide transactionsettlement and clearance services not only to customers involved ininitiated payment transactions, but also to additional financialinstitutions that provide transaction settlement and clearance servicesto corresponding customers. As these additional financial institutionsaccess the one or more transaction processing networks through acorresponding direct participant, each of these additional financialinstitutions may represent an indirect participant in the one or moretransaction processing networks.

Further, as a direct participant in the one or more transactionprocessing networks, the financial institution may also be associatedwith, operate, or maintain one or more computing systems (e.g., a“direct clearing” system) configured to communicate directly across oneor more communications networks with computing systems operated by theone or more transaction processing networks (e.g., one or more“transaction processing” systems). In some examples, the direct clearingsystem may receive payment instructions, which identify and characterizethe payment transactions, from a computing system operated by, orassociated with, the indirect participant in the one or more transactionnetworks (e.g., an “indirect clearing” system). Upon receipt the paymentinstructions from the indirect clearing system, the direct clearingsystem may store the payment instructions in a locally accessible datarepository and/or in a secure, cloud-based data repository, may formatthe received portion of the payment instructions for consistency with adata-interchange format associated with the one or more transactionprocessing networks, and further, may submit the formatted paymentinstructions to the one or more transaction processing systems.

The one or more transaction processing systems may perform operationsthat settle and clear each of these additional payment transactions inaccordance with the payment instructions, and may generate and transmitdata confirming a status of the settlement and clearance of each of thepayment transactions to the direct clearing system. In some examples,the direct clearing system may perform operations that reconcile theadditional confirmation data against locally stored portion of thepayment instructions and additionally, or alternatively, on portions ofstored account data associated with the indirect participant (e.g., asettlement account, etc.), and generate elements of reconciliation dataindicative of an outcome of the reconciliation process for each of thepayment transactions, which the direct clearing system may store withinthe locally accessible data repository or the secure, cloud-based datarepository. The direct clearing system may route the additionalconfirmation data, and in some instances, the additional elements ofreconciliation data, to the indirect clearing system.

The indirect clearing system may perform processes that locallyreconcile the additional confirmation data against the locally storedpayment instructions and additionally, or alternatively, on portions ofstored account data associated with each of the customers, and generatecorresponding elements of local reconciliation data indicative of anoutcome of the local reconciliation processes, which the indirectclearing system may store within the locally accessible data repositoryor the secure, cloud-based data repository. The indirect clearing systemmay also provide portions of the confirmation data, which characterize astatus of the clearance and settlement of corresponding ones of thepayment transactions, to each of the network-connected devices orsystems associated with, or operated by, the customers, e.g., forpresentation within a digital interface.

Due to limitations in bandwidth or capacity in many existing transactionprocessing networks, and due to the multiple reconciliation processesperform by the direct and indirect clearing systems, certainconventional clearance and settlement processes may increase a pendencyof an initiated payment transaction and increase a time required for theindirect clearing system to reconcile payment transactions cleared andsettled indirectly and on behalf of the indirect participant by thedirect clearing system. Further, as the indirect clearing system may beincapable of accessing directly the one or more transaction processingsystems, certain of these conventional processes may limit a capabilityof the indirect clearing system to access settlement reports generatedby the transaction processing system and as such, may obfuscate a statusof a settled payment transaction prior to a completion of areconciliation process by the direct clearing system.

In some exemplary embodiments, as described herein, the indirect anddirect clearing systems may, in conjunction with other peer computingsystems, establish and participate in a permissioned, distributed-ledgernetwork, and may perform consensus-based operations that establish andmaintain a cryptographically secure and permissioned distributed ledgerthat immutable records, within one or more ledger blocks, encryptedpayment summary, settlement status, and/or reconciliation status datacharacterizing one or more initiated payment transactions at discretestages of the clearance and settlement process. As described herein, theencrypted payment summary, settlement status, and/or reconciliationstatus data may also be recorded onto the ledger blocks of thedistributed ledger in conjunction with additional information thatenables the indirect and direct clearing systems to identify accessibleportions of the encrypted payment summary or payment reconciliation data(via a corresponding public cryptographic key) within the ledger blocksand to establish an integrity and authenticity of the encrypted paymentsummary, settlement status, and/or reconciliation status data.

Certain of these exemplary embodiments, which recordparticipant-specific portions of encrypted payment summary, settlementstatus, and/or reconciliation status data onto a distributed ledger, mayenable participants in a permissioned distributed ledger-network, suchas the indirect and direct clearing systems described herein, to track astatus of an initiated payment transaction in real-time throughout theclearance and settlement process. These exemplary processes can beimplemented in addition to, or as an alternate to, the conventionalclearance and settlement processes described herein, and can increasenot only a visibility of these clearance and settlement processes toeach of the participants in the permissioned distributed-ledger network,and but also an accuracy, speed, and security of the reconciliationprocesses described herein. Further, certain of these exemplaryprocesses can establish a cryptographically secure, immutable, andtamper-evident audit trail that reduces a potential for fraudulent ormalicious activity, either by the participants in the permissioneddistributed-ledger network or by other computing systems operated byunauthorized third parties.

FIG. 1 illustrates components of an exemplary computing environment 100,in accordance with some exemplary embodiments. As illustrated in FIG. 1, environment 100 may include one or more computing devices, such as apayer device 102 associated with a payer 103. Environment 100 may alsoinclude one or more computing systems associated with a transactionprocessing network, such as transaction processing system 112, one ormore computing systems associated with indirect or direct participantsin that transaction processing network, such as a payer indirectclearing system 122 and payer direct clearing system 142, and one ormore peer systems 160, such as peer system 162. Further, although notillustrated in FIG. 1 , environment 100 may also include one or moreadditional, or alternate, computing devices or systems, such as, but notlimited to, a computing device operated by one or more payees, acomputing system operated by a direct or indirect clearer associatedwith the one or more payees, and a computing system associated with, oroperated by, a corresponding regulatory or governmental entity.

As illustrated in FIG. 1 , each of payer device 102, transactionprocessing system 112, payer indirect clearing system 122, payer directclearing system 142, and peer systems 160, including peer system 162,may be interconnected through any combination of communicationsnetworks, such as network 120. Examples of network 120 include, but arenot limited to, a wireless local area network (LAN), e.g., a “Wi-Fi”network, a network utilizing radio-frequency (RF) communicationprotocols, a Near Field Communication (NFC) network, a wirelessMetropolitan Area Network (MAN) connecting multiple wireless LANs, and awide area network (WAN), e.g., the Internet.

Payer device 102 may, in some instances, correspond a computing devicethat includes one or more tangible, non-transitory memories storing dataand software instructions, and one or more processors coupled to the oneor more tangible, non-transitory memories and configured to execute thestored software instructions. As described herein, payer device 102 maybe associated with or operated by a corresponding user, such as payer103, and examples of payer device 102 include, but are not limited to,as a smart phone, tablet computer, a desktop computer, a gaming console,a wearable device, or another computing device, system, or apparatusassociated with a payer 103.

In some instances, each of transaction processing system 112, payerindirect clearing system 122, payer direct clearing system 142, and peersystems 160 (including peer system 162) may represent a computing systemthat includes one or more servers and tangible, non-transitory memorydevices storing executable code and application modules. The servers mayeach include one or more processors or processor-based computingdevices, which may be configured to execute portions of the stored codeor application modules to perform operations consistent with thedisclosed embodiments. Further, in some examples, each of transactionprocessing system 112, payer indirect clearing system 122, payer directclearing system 142, and peer systems 160 (including peer system 162)may each include a communications interface coupled to the one or moreprocessors for accommodating wired or wireless communication acrossnetwork 120 with any of the additional network-connected systems ordevices described herein, e.g., a transceiver device.

In other instances, one or more of transaction processing system 112,payer indirect clearing system 122, payer direct clearing system 142,and peer systems 160 (including peer system 162) may correspond to adistributed system that includes computing components distributed acrossone or more networks, such as network 120, or other networks, such asthose provided or maintained by cloud-service providers. Further, one ormore of transaction processing system 112, payer indirect clearingsystem 122, payer direct clearing system 142, and peer systems 160(including peer system 162) can be incorporated into a single computingsystem, as described herein.

Payer indirect clearing system 122 and payer direct clearing system 142may perform operations that, among other things, initiate, execute,monitor, or reconcile exchanges of data based on information generatedby payer device 102, e.g., based on an interaction within one or moreadditional computing systems operating within environment 100, such as,but not limited to, transaction processing system 112. For instance, andas described herein, the exchanges of data may correspond to, or mayfacilitate, one or more payment transactions that electronicallytransfer funds from a source account held by payer 103 at a payerfinancial institution to one or more destination accounts held bycorresponding payees and other counterparties, e.g., in satisfaction ofan existing or ongoing obligation. Examples of these paymenttransactions can include, but are electronic funds transfer (EFT)transactions between counterparties, automated funds transfer (AFT)credit transactions between counterparties (e.g., that facilitatepayroll processing) and/or AFT debit transactions between counterparties(e.g., that facilitate bill payment transactions, such as mortgagepayments, etc.).

In some instances, the payer financial institution may represent anindirect participant in one or more transaction processing networks,such as one or more payment rails that settle one or more of theexemplary payment transactions described herein. Although one or morecomputing systems associated with, operated by, or maintained by thepayer financial institution (e.g., payer indirect clearing system 122 ofFIG. 1 ) may receive payment instructions characterizing one or morepayment transactions directly from payer device 102, payer indirectclearing system 122 may be incapable of directly accessing a computingsystem associated with the one or more transaction processing networks(e.g., transaction processing system 112) or a programmatic interfacemaintained by transaction processing system 122, and as such, paymentindirect clearing system 122 may be incapable of directly submittingdirect payment instructions for settlement.

Instead, and as described herein, payer indirect clearing system 122 maybe configured to route received payment instructions across network 120to one or more computing systems associated with, or operated by, adirect participant in the one or more transaction processing networks,such as, but not limited to, payer direct clearing system 142. Uponreceipt of the payment instructions, payer direct clearing system 142may perform any of the exemplary processes described herein to map ortransform elements of the received payment instructions into a formatappropriate for processing by transaction processing system 112, and tosubmit the formatted payment instructions to transaction processingsystem 112 directly across a secure, programmatic interface forsettlement by the one or more transaction processing networks.

To facilitate a performance of these exemplary processes, payer indirectclearing system 122 may maintain, within the one or more tangible,non-transitory memories, a data repository 124 that includes, but is notlimited to, a cryptographic library 126, an account database 128, and atransaction database 130. In some instances, cryptographic library 126may include an asymmetric cryptographic key pair associated with,generated by, or assigned to payer indirect clearing system 122 (e.g., aprivate cryptographic key and a corresponding public cryptographic key),along with public key certificates associated with one or moreadditional computing systems within environment 100, such as, but notlimited to, payer direct clearing system 142 or other computing systemsassociated with or operated by a financial institution associated withone or more payees involved in corresponding payment transactions.Account database 128 may include structured or unstructured data recordsthat identify and characterize one or more financial services accountsissued by the payer financial institution to payer 103 and othercustomers, and in some instances, transaction database 130 may includestructured or unstructured data records that identify and characterizeone or more exchanges of data (e.g., payment transactions) received frompayer device 102 and routed to direct clearing system 142.

Further, and to facilitate a performance of these exemplary processes,payer direct clearing system 142 may maintain, within the one or moretangible, non-transitory memories, a data repository 144 that includes,but is not limited to, a cryptographic library 146, mapping data 148, anaccount database 150, and a transaction database 152. In some instances,cryptographic library 146 may include an asymmetric cryptographic keypair associated with, generated by, or assigned to payer direct clearingsystem 142 (e.g., a private cryptographic key and a corresponding publiccryptographic key), along with public key certificates associated withone or more additional computing systems within environment 100, suchas, but not limited to, payer indirect clearing system 122 or othercomputing systems associated with or operated by a financial institutionassociated with one or more payees involved in corresponding paymenttransactions.

Mapping data 148 may include data that maps or transforms one or moreelements of data structured in accordance with a standardizeddata-interchange format, such as an ISO 20022™ standard data-interchangeformat, into corresponding elements of data structured in accordancewith one or more legacy data-interchange formats, e.g., a legacydata-interchange format associated with and suitable for processing bytransaction processing system 112. Account database 150 may includestructured or unstructured data records that identify and characterizeone or more financial services accounts issued to one or more customersof payer direct clearing system 142, such as a settlement account issuedto and maintained on behalf of payer indirect clearing system 122.Further, transaction database 152 may include structured or unstructureddata records that identify and characterize one or more exchanges ofdata (e.g., payment transactions) submitted for settlement using any ofthe exemplary processes described herein, e.g., based on portions ofpayment data routed from payer indirect clearing system 122 to payerdirect clearing system 142.

Transaction processing system 112 may be associated with, or operatedby, the one or more transaction processing networks, examples of whichinclude, but are not limited to, a legacy payment rail that facilitatesa clearance and settlement of electronic funds transfer (EFT)transactions between counterparties and a legacy payment rail thatfacilitates automated funds transfer (AFT) credit transactions betweencounterparties (e.g., that facilitate payroll processing) and/or AFTdebit transactions between counterparties (e.g., that facilitate billpayment transactions, such as mortgage payments, etc.). In someinstances, transaction processing system 112 may be configured toreceive, from payer direct participant system 142, elements oftransaction data structured in accordance with a legacy data-interchangeformat (e.g., specified within mapping data 148), and to perform anyexemplary processes described herein to settle payment transactionsbased on the legacy transaction data, e.g., to execute the paymenttransactions.

One or more of peer systems 160, including peer system 162, may performconsensus-based operations that establish and maintain a permissioneddistributed ledger. In some instances, the permissioned distributedledger may immutably record and track selectively encrypted elements ofdata summarizing a status of one or more payment transactions atdiscrete temporal positions during one or more of the exemplarytransaction settlement, clearance, and reconciliation processesimplemented collectively by transaction processing system 112, payerindirect clearing system 122, payer direct clearing system 142, andother direct and indirect clearing systems associated with a payee orpayee financial institution (not illustrated in FIG. 1 ).

Based on an implementation of the exemplary consensus-based processeddescribed herein, peer systems 160 (including peer system 162) maygenerate one or more ledger blocks of the permissioned distributedledger that record selectively encrypted portions of payment summarydata, settlement status data, or reconciliation status data (e.g., asreceived from payer indirect clearing system 122, payer direct clearingsystem 142, and the other payee direct and indirect clearing systems),and may append these newly additional ledger blocks to the permissioneddistributed ledger to generate an updated version of the permissioneddistributed ledger. In addition to, or as alternate to the selectivelyencrypted elements portions of payment summary data, settlement statusdata, or reconciliation status data, the additional ledger blocks mayinclude selectively encrypted pointer data identifying a storagelocation of that payment summary data, status data, or reconciliationdata. Examples of the pointer data include, but are not limited to, anHTML file path, a uniform resource locator (URL), or other informationthat uniquely identifies a corresponding storage location within thecloud-based data repository.

One or more peer systems 160, including peer system 162, may beconfigured to broadcast the updated version of the permissioneddistributed ledger to payer indirect clearing system 122, payer directclearing system 142, and the other direct and indirect clearing systems(not illustrated in FIG. 1 ) that, in conjunction with peer systems 160,collectively establish a permissioned, distributed-ledger network. Forexample, payer indirect clearing system 122, payer direct clearingsystem 142, and the other direct and indirect clearing systems may eachreceive the updated version of the permissioned distributed ledger,e.g., as broadcast by peer systems 160, and may store the updatedversion of the permissioned distributed ledger within corresponding onesof the tangible, non-transitory memories, e.g., as distributed ledger170.

To facilitate a performance of any of the exemplary processes describedherein, peer system 162 may establish and maintain, within the one ormore tangible, non-tangible memories, one or more structured orunstructured data repositories or databases, such as data repository164. By way of example, data repository 164 may include, but is notlimited to, a cryptographic library 166 that includes an asymmetriccryptographic key pair (e.g., a private cryptographic key and acorresponding public cryptographic key) generated by, associated with,or assigned to peer system 162. Peer system 162 may also store a currentversion of the distributed ledger, e.g., distributed ledger 170, withina corresponding portion of data repository 164. Further, although notillustrated in FIG. 1 , each additional peer system of peer systems 160may include components similar to those described herein in reference topeer system 162, and may store similar elements of data in datarepositories establishing within corresponding ones of the tangible,non-transitory memories.

Referring to FIG. 2A, the one or more processors of payer device 102 mayexecute an application program, e.g., payment application 202, thatcauses payer device 102 to generate transaction data 204 identifying oneor more initiated payment transactions. For example, the one or morepayment transactions may include to a payment transaction that satisfiesan outstanding invoice for products purchased by payer 103 from acorresponding counterparty (e.g., a merchant), and payer device 102 maymaintain, within the one or more transitory memories, invoiceinformation 203 that includes, among other things, structured datacharacterizing the outstanding invoice and enriched content associatedwith the outstanding invoice.

For example, the outstanding invoice may be associated with a balance of$7,500.00 for products shipped to payer 103 on Apr. 5, 2019, and may beassociated with a due date of May 1, 2019. In some instances, thestructured data that characterizes the outstanding invoice may include,but is not limited to, remittance information (e.g., an account orrouting number associated with a financial services account held by themerchant), the outstanding balance of $7,500.00, and the due date of May1, 2019. Further, examples of the enriched content associated with theoutstanding invoice include, but are not limited to, an electronic copyof one or more pages of the invoice, a packing list associated with theApril 5^(th) shipment, and additionally, or alternatively, acorresponding purchase order.

In some instances, executed payment application 202 may generate element206 of transaction data 204, which corresponds to the paymenttransaction involving the outstanding invoice. For example, executedpayment application 202 may determine a value of one or more parametersthat characterize the payment transaction based on portions of invoiceinformation 203. Examples of these determined parameter values caninclude, but are not limited to, a transaction type (e.g., an EFTtransaction, an AFT credit or debit transaction, etc.), a transactionamount (e.g., the outstanding balance, a different amount reflecting acredit, etc.), a transaction date or time (e.g., a predetermined orspecified time prior to the due date of May 1^(st), such as seven days),a payer identifier (e.g., a name or unique identifier of payer 103), anidentifier of a source account (e.g., a routing and/or account number ofa deposit account held by payer 103 and issued by a correspondingfinancial institution), an identifier of a payee (e.g., a name or uniqueidentifier of the merchant) and additionally, or alternatively, anidentifier of a destination account (e.g., the routing and/or accountnumber of the merchant).

As illustrated in FIG. 2A, payment application 202 may package thedetermined parameter values into corresponding portions of paymentinstruction information 208, which may be incorporated into transactiondata element 206. Further, executed payment application 202 may alsoperform operations that further parse invoice information 203 to extractall or a portion of the enriched content (e.g., the electronic copies ofthe invoice or the purchase order, etc.), and that package the extractedportions of the enriched content into corresponding portions of richtransaction remittance data 210, which may also be included withintransaction data element 206. In other instances, rich transactionremittance data 210 may also include additional information thatcharacterizes the payment transaction associated with the outstandinginvoice, such as, but not limited to, payment advice characterizing adiscrepancy between the transaction amount and the balance of theoutstanding invoice.

By way of example, transaction data element 206, and each of paymentinstruction information 208 and rich transaction remittance data 210,may be structured in accordance with an appropriate data-exchangeformat, such as the ISO 20022™ standard data-interchange formatdescribed herein. Further, executed payment application 202 may package,into corresponding portions of transaction data 204 (e.g., into a headerportion, etc.), additional information that, among other things,identifies payer 103 (e.g., a login credential or digital identifier),payer device 102 (e.g., an Internet Protocol (IP) address) and/orexecuted payment application 102 (e.g., an application cryptogram, suchas a hash value, random number, cryptographic key, etc.). Additionally,executed payment application 202 may perform any of the exemplaryprocesses described herein to generate elements of transaction data 204that are associated with, and characterize, one or more additionalpayment transactions.

Executed payment application 202 may perform operations that cause payerdevice 102 to transmit, via a corresponding communications interface(e.g., a transceiver device), transaction data 204 across network 120 toone or more computing systems associated with the financial institutionof payer 103, such as, but not limited to, payer indirect clearingsystem 122. As illustrated in FIG. 2A, payer indirect clearing system122 may receive transaction data 204 (e.g., via a correspondingcommunications interface), and a secure, programmatic interface of payerindirect clearing system 122, e.g., application programmatic interface(API) 212, may route transaction data 204 to a transaction engine 214executed by payer indirect clearing system 122.

A validation module 216 of executed transaction engine 214 may receivetransaction data 204, and may perform operations that validatetransaction data 204. For example, validation module 216 may access oneor more portions of transaction data 204 (e.g., a header portion, afooter portion, etc.) and extract the information that identifies payer103 (e.g., the login credential or digital assigned to payer 103), payerdevice 102 (e.g., the IP address), and/or executed payment application202 (e.g., the application cryptogram). Validation module 216 mayperform operations that validate transaction data 204 based on acomparison between the extracted information and correspondingidentifiers maintained within account database 128. Additionally, oralternatively, validation module 216 may perform operations thatvalidate transaction data 204 based on a comparison of the extractedapplication cryptogram to a locally computed copy of the applicationcryptogram, or based on a determination that the application cryptogramconforms to a predetermined format.

If validation module 216 were unable to validate transaction data 204,executed transaction engine 214 may perform operations that discardtransaction data 204, and that cause payer indirect clearing system 122to generate and transmit an error message to payer device 102 (notillustrated in FIG. 2A). Alternatively, if validation module 216 wereable to validate transaction data 204, validation module 216 may packagenow-validated transaction data 204 into a corresponding portion ofvalidated transaction data 218. As illustrated in FIG. 2A, validationmodule 216 may provide validated transaction data 218, which includesnow-validated transaction data element 206, an input to an indirectsettlement module 220 of executed transaction engine 214.

Indirect settlement module 220 may perform operations that assign aunique alphanumeric identifier, e.g., a correlation identifier, to eachelement of validated transaction data 218. The assigned correlationidentifiers may be characterized by a predetermined length or apredetermined structure, and examples of the correlation identifiersinclude, but are not limited to, a random number or a hash valuegenerated based on portions of corresponding elements of validatedtransaction data 218. In some instances, indirect settlement module 220may package each element of validated transaction data 218, and theassigned correlation identifier, into a corresponding element ofcorrelated transaction data 222, which indirect settlement module 220may store within transaction database 130.

By way of example, indirect settlement module 220 may assign acorrelation identifier 224 to transaction data element 206 (e.g., asincluded within validated transaction data 218), and may packagecorrelation identifier 224 and transaction data element 206 into acorresponding element 226 of correlated transaction data 222. Indirectsettlement module 220 may perform similar assignment and storageoperations for each additional element of validated transaction data 218and each of the additional correlation identifiers. Further, as eachelement of validated transaction data 218 may be structured inaccordance with the ISO 20022™ standard data-interchange format, theelements of correlated transaction data 222 may also include structuredpayment instruction information (e.g., payment instruction information208 of transaction data element 206) and rich transaction remittancedata (e.g., rich transaction remittance data 210 of transaction dataelement 206).

In some instances, the predetermined length, format, or structure of theassigned correlation identifiers may be specified by one or moreadditional computing systems operating within environment 100 havingaccess to transaction processing network 100, such as payer directclearing system 142, and indirect settlement module 220 may compute eachof the correlation identifiers based on an algorithm or other rubricprovided by payer direct clearing system 142. In other instances,indirect settlement module 220 may perform operations that request andreceive a portion of the correlation identifiers from payer directclearing system 142, which itself may generate the requested portion ofthe correlation identifiers or obtain the requested portion of thecorrelation identifiers from transaction processing system 112.

As described herein, the payer financial institution may represent anindirect participant in the transaction processing networks that settleand clear the payment transaction specified within correlatedtransaction data 222, and as such, neither the payer financialinstitution nor payer indirect clearing system 122 may access the one ormore transaction networks that clear and settle the paymenttransactions. In some instances, indirect settlement module 220 mayperform additional operations that package all or a portion ofcorrelated transaction data 222 into a request 228 for indirectsettlement of the payment transactions. Further, to establish anintegrity of each element of correlated transaction data 222, indirectsettlement module 220 may also apply a digital signature 229 to thecorrelated transaction data 222 (e.g., using any appropriate keygeneration algorithm in conjunction with a private cryptographic keyassigned to payer indirect clearing system 122), and package the applieddigital signature 229 into a corresponding portion of settlement request228.

In some instances, indirect settlement module 220 may also package, intocorresponding portions of settlement request 228, an identifier 230 ofpayer indirect clearing system 122 (e.g., an IP address, a uniquedigital identifier, such as a cryptogram or hash value, etc.).Additionally, or alternatively, indirect settlement module 220 may alsopackage, into a corresponding portion of settlement request 228, data232 that identifies a settlement account maintained on behalf of thepayer financial institution by a direct participant in the one or moretransaction processing network, e.g., the financial institutionassociated with payer direct clearing system 142. Indirect settlementmodule 220 may also perform operations that store identifier 230,settlement account data 232, and the elements of correlated transactiondata within a portion of data repository 124, e.g., within the datarecords of transaction database 130.

Additionally, or alternatively, indirect settlement module 220 mayperform also operations that transmit elements of correlated transactiondata 222 across network 120 to one or more computing systems associatedwith a cloud-based repository, e.g., via a secure programmatic interface(not illustrated in FIG. 2A). In some instances, rather than storingactual elements of correlated transaction data 222 within transactiondatabase 130, e.g., in conjunction with identifier 230 and settlementaccount data 232, transaction database 130 may maintain pointer dataidentifying a location of each of the elements of correlated transactiondata 222 within the cloud-based repository.

Executed transaction engine 214 may perform operations that cause payerindirect clearance system 122 to transmit settlement request 228 acrossnetwork 120 to payer direct clearing system 142, e.g., through a secure,programmatic interface. In some instances, payer direct clearing system142 may perform any of the exemplary processes described herein to clearand reconcile each of the payment transactions specified withinsettlement request 228, and to submit data characterizing these clearedand reconciled payment transaction to transaction processing system 112,e.g., for settlement in accordance with the reconciled transactionparameter values. Further, and as described herein, payer directclearing system 142 may perform additional operations that, inconjunction with peer systems 160, record selectively encrypted elementsof payment summary data, reconciliation status data, and/or settlementstatus data within one or more ledger blocks of a permissioneddistributed ledger, and facilitate an implementation of time-efficientand cryptographically secure process for reconciling the settled paymenttransactions at payer indirect clearing system 122.

Referring back to FIG. 2A, executed transaction engine 214 may alsoprovide correlated transaction data 222 as an input to a status module234, which may process portions of correlated transaction data 222 togenerate discrete elements of status data 236, which characterize eachof the initiated payment transaction specified within correlatedtransaction data 222. By way of example, and for each of the initiatedpayment transactions, transaction status module 234 may extract acorresponding one of the correlation identifiers, and package portionsof the payment instruction information (e.g., the transaction parametervalues described herein) and/or rich transaction remittance data into acorresponding element of payment summary data. Further, and for each ofthe payment transactions, transaction status module 234 may generate acorresponding element of settlement status data, which confirms thecurrent status of the indirect settlement process, i.e., that payerindirect clearing system 122 transmitted settlement request 228 todirect clearing system 142).

For example, and for the particular payment transaction involving theoutstanding invoice for $7,500.00, transaction status module 234 mayaccess element 226 of correlated transaction data 222. As describedherein, element 226 includes correlation identifier 224, which uniquelyidentifies the particular payment transaction, and transaction dataelement 206, which includes payment instruction information 208 and richremittance transaction data 210. As illustrated in FIG. 2A, transactionstatus module 234 may package all or a portion of payment instructioninformation 208 into corresponding portions of payment summary data 238(e.g., either alone or in conjunction with all, or a potion, of richremittance transaction data 210), and may generate settlement statusdata 240 that confirms the current status of the payment transactionwithin the indirect clearance and settlement processes described herein.

In some instances, status module 234 may package correlation identifier224, payment summary data 238, and settlement status data 240 into acorresponding element 242 of status data 236, and may perform any of theprocesses described herein to generate an additional element of statusdata 236 for each additional payment transaction specified withincorrelated transaction data 222. Transaction status module 234 mayprovide payment summary and status data 236 as an input to a blockgeneration module 244, which may be executed by the one or moreprocessors of payer indirect clearing system 122.

In some instances, the elements of payment summary data and settlementstatus data that characterize each of the initiated payment transactionsmay include actual values of corresponding transaction parameters (e.g.,within the payment summary data) or actual status data characterizingthe position the initiated payment transaction within the indirectsettlement processes described herein (e.g., within the settlementstatus data). In other instances, and consistent with the disclosedexemplary embodiments, one or more of the elements of payment summarydata and settlement status data include pointer data that identifies astorage location of an appropriate data element within a cloud-basedrepository to accessible to payer indirect clearing system 122 and/orpayer direct clearing system 142, e.g., across network 120 via thesecure programmatic interface. Examples of the pointer data include, butare not limited to, an HTML file path, a uniform resource locator (URL),or other information that uniquely identifies a corresponding storagelocation within the cloud-based data repository.

Referring to FIG. 2B, executed block generation module 244 may receivestatus data 236, which includes element 242 characterizing theparticular payment transaction for the outstanding invoice of $7,500.00,and may access cryptographic library 126, e.g., as maintained withindata repository 124. In some instances, block generation module 244 mayperform operations that extract, from cryptographic library 126: (i)cryptographic data 246 that includes a private cryptographic keyassociated with payer indirect clearing system 122 and a correspondingpublic key certificate 262, which includes a corresponding publiccryptographic key of payer indirect clearing system 122; and (ii)cryptographic data 248 that includes a public key certificate 265 ofpayer direct clearing system 142, which includes a corresponding publiccryptographic key.

Block generation module 244 may perform operations that encrypt each ofthe status data 236 using the public cryptographic key of payer directclearing system 142, and may generate corresponding elements ofencrypted status data 250. By way of example, element 252 of encryptedstatus data 250 characterizes the particular payment transactionassociated with the outstanding invoice of $7,500.00, and includes anencrypted correlation identifier 254 (e.g., based on correlationidentifier 224), encrypted payment summary data 256 (e.g., based onpayment summary data 238), and encrypted payment status data (e.g.,based on settlement status data 240). Although not illustrated in FIG.2B, encrypted status data 250 may include additional encrypted elementsthat characterize each of the additional payment transactioncharacterized by status data 236, each of which include encryptedinformation similar to that included within element 252.

In some instances, block generation module 244 may apply a digitalsignature 260 to the elements of encrypted status data 250 using theprivate cryptographic key of payer indirect clearing system 122, e.g.,as extracted from cryptographic data 246. Block generation module 244may package encrypted status data 250, digital signature 260, and publickey certificate 262 of payer indirect clearing system 122 intocorresponding portions of a recordation request 266. As illustrated inFIG. 2B, block generation module 244 may perform operations that causepayer indirect clearing system 122 to broadcast recordation request 266across network 120 to each of peer systems 160, including peer system162.

A programmatic interface of peer system 162 (and each additional oralternate one of peer systems 160), such as application programminginterface (API) 268, may receive recordation request 266, and may routerecordation request 266 to a block generation module 270. When executedby the one or more processors of peer system 162 (and each additional oralternate one of peer systems 160), block generation module 270 mayperform operations that generate a new ledger block 272 that includesencrypted status data 250, digital signature 260, and public keycertificate 262 of payer indirect clearing system 122. Block generationmodule 270 may also perform operations that apply a digital signature274 to a payload 273 of new ledger block 272, e.g., encrypted statusdata 250, digital signature 260, and public key certificate 262, using acorresponding private cryptographic key of peer system 162 maintainedwithin cryptographic library 166.

Further, block generation module 270 may also generate a hash value 276based on an application of any appropriate hash algorithm to payload273, either alone or in conjunction with a corresponding publiccryptographic key 278 of peer system 162. In some instances, blockgeneration module 270 may perform operations that digital signature 274,hash value 276, and public cryptographic key 278 into correspondingportions of new ledger block 272, along with payload 273, e.g.,encrypted status data 250, digital signature 260, and public keycertificate 262.

Peer system 160 (and each additional or alternate one of peer systems160) may perform additional operations that append to ledger block 272to a prior version of the permissioned distributed ledger to generate alatest, longest version of the permissioned distributed ledger (e.g., anupdated distributed ledger 280). For example, the additional operationsmay be established through distributed consensus among peer systems 160,and may include, but are not limited to, the calculation of anappropriate proof-of-work or proof-of-stake by a distributed consensusmodule 282 prior to the other peer systems. In certain aspects, peersystem 162 may broadcast evidence of the calculated proof-of-work orproof-of-stake to the additional ones of peer systems 160 across network120 (e.g., as consensus data 184).

Peer system 162 may also broadcast updated distributed ledger 280, whichrepresents the latest, longest version of the distributed ledger, to theadditional ones of peer systems 160 operating within environment 100 andadditionally or alternatively, to each of the network-connected systemsthat participate in the permissioned, distributed-ledger network, suchas payer indirect clearing system 122 and payer direct clearing system142. In some instances, not illustrated in FIG. 2B, each of payerindirect clearing system 122, payer direct clearing system 142, and theadditional ones of peer systems 160 may perform operations that storeupdated distributed ledger 280 within respective portions of datarepository 124, data repository 144, and/or data repository 164, e.g.,to replace distributed ledger 170.

In one example, new ledger block 272 of updated distributed ledger 280may include, within payload 273, encrypted payment summary data andencrypted settlement status data for one or more initiated paymenttransactions, e.g., within encrypted status data 250. In other examples,encrypted status data 250 may include encrypted elements of pointer datathat identify a storage location of corresponding elements of thepayment status data within one or more of the cloud-based repositoriesdescribed herein, and additionally, or alternatively, encrypted elementsof pointer data that identify a storage location of correspondingelements of the settlement status data within the one or morecloud-based repositories.

As described herein, payer indirect clearing system 122 may performfurther operations that transmit settlement request 228 across network120 to one or more computing systems associated with, or operated by,the direct participant in the transaction processing networks, such as,but not limited to, payer direct clearing system 142. In some instances,described below in reference to FIGS. 3A and 3B, payer direct clearingsystem 142 may perform any of the exemplary processes described hereinto submit formatted payment instructions characterizing the paymenttransactions specified within settlement request 228 directly totransaction processing system 112 for settlement. Payer direct clearingsystem 142 may also perform operations that, in conjunction with peersystems 160, record selectively encrypted elements of payment summarydata, settlement status data, and/or reconciliation status data withinone or more ledger blocks of a permissioned distributed ledger, whichfacilitate an implementation of cryptographically secure andtamper-resistant processes for reconciling the each of the settledpayment transactions at payer indirect clearing system 122.

Referring to FIG. 3A, payer direct clearing system 142 may receivesettlement request 228, e.g., across network 120 from payer indirectclearing system 122. As described herein, settlement request 228 mayinclude, among other things, correlated transaction data 222, whichidentifies and characterizes one or more payment transaction initiatedat payer device 102, along with identifier 230 that identifies payerindirect clearing system 122 (e.g., an IP address, a cryptogram, etc.)and/or data 232 that identifies a settlement account of payer indirectclearing system 122. As illustrated in FIG. 3A, a secure, programmaticinterface of payer direct clearance system 142, e.g., API 302, may routesettlement request 228 to a transaction engine 304 executed by the oneor more processors of payer direct clearance system 142.

In some instances, a validation module 306 of executed transactionengine 304 may receive settlement request 228 and perform operationsthat validate settlement request 228. By way of example, validationmodule 306 may access settlement request 228, and may extract identifier230 (e.g., an IP address, a cryptogram, etc. of payer indirect clearingsystem 122) and additionally, or alternatively, settlement account data232 (e.g., an account number, a tokenized account number, etc. of thesettlement account held by of payer indirect clearing system 122).Validation module 306 may, for example, perform operations thatauthenticate an identity of payer indirect clearing system 122 based ona comparison of identifier 230, such as the IP address, against one ormore data records of account database 150 that correspond to thesettlement account of payer indirect clearing system 122 (e.g., thatinclude or are associated with settlement account data 232).

In other examples, validation module 306 may also authenticate theidentity of payer indirect clearing system 122 based on a validation ofthe cryptogram extracted from identifier 230, e.g., based on acomparison with a locally computed copy of the extracted cryptogram or adetermination that the extracted cryptogram conforms to a predeterminedformat. Further, in some examples, validation module 306 may performoperations that validate digital signature 229 using a publiccryptographic key of payer indirect clearing system 122 (e.g., asmaintained within cryptographic library 146), and based on thevalidation of digital signature 229, not only authenticate the identityof payer indirect clearing system 122, but also verify an integritysettlement request 228.

If validation module 216 were unable to authenticate the identity ofpayer indirect clearing system 122 or to verify the integrity ofsettlement request 228, executed transaction engine 304 may performoperations that discard settlement request 228. In some instances,executed transaction engine 304 may perform operations that cause payerdirect clearing system 142 to generate and transmit an error message(not illustrated in FIG. 3A).

Alternatively, if validation module 306 were able to authenticate theidentity of payer indirect clearing system 122 and verify the integrityof settlement request 228, validation module 216 may route settlementrequest 228 to a management module 308 of execution transaction engine304. In some instances, management module 308 may perform operationsthat parse settlement request 228, and extract identifier 230 of payerindirect clearance system 122, settlement account data 232, andcorrelated transaction data 222. As illustrated in FIG. 3A, managementmodule 308 may access transaction database 152 (e.g., as maintainedwithin data repository 144), and may perform operations that linktogether and store identifier 230 and correlated transaction data 222within one or more data records 310 of transaction database 152.

Additionally, or alternatively, management module 308 may performoperations that transmit identifier 230 and correlated transaction data222 across network 120 to the one or more computing systems associatedwith the cloud-based repository, e.g., via a secure programmaticinterface (not illustrated in FIG. 3A). In some instances, rather thanstoring actual elements of correlated transaction data 222 withintransaction database 152, e.g., in conjunction with identifier 230,transaction database 152 may maintain pointer data identifying alocation of each of the elements of correlated transaction data 222within the cloud-based repository.

Management module 308 may also provide correlated transaction data 222to a reconciliation module 312 of executed transaction engine 304. Insome instances, reconciliation module 312 may perform operations that,among other things, verify that an available balance in the settlementaccount of payer indirect clearing system 122 is equivalent to, orexceeds, an aggregated transaction value of the payment transactionssubmitted for settlement by payer indirect transaction system 122. Byway of example, reconciliation module 312 may access one or more datarecords of account database 150, which corresponds to the settlementaccount of payer indirect clearing system 122 (and with includes orreferences a portion of settlement account data 232), and access balancedata 316, which specifies the available balance of the settlementaccount. Further, reconciliation module 312 may also access each elementof correlated transaction data 222, identify a transaction amountcorresponding to each of the access elements, and compute an aggregatetransaction value across the payment transactions submitted by payerindirect clearing system 122 for settlement.

If, for example, reconciliation module 312 were to determine that theavailable balance of the settlement account is equivalent to, or exceedsthe aggregate transaction value, reconciliation module 312 may establishthat the available balance within the settlement account is sufficientto fund each of the initiated payment transactions (e.g., initiatedtransfers to the destination accounts of the counterparties). In someinstances, reconciliation module 312 may package each element ofcorrelated transaction data 222, including element 226 representative ofthe payment transaction that funds the outstanding invoice for$7,500.00, into a corresponding portion of reconciled transaction data318, which reconciliation module 312 may provide as an input to a directsettlement module 320 of executed transaction engine 304.

Further, as illustrated in FIG. 3A, reconciliation module 312 may alsogenerate elements of reconciliation data 322 that, for example, identifythe available balance of the settlement account and/or the aggregatevalue of the initiated payment transactions, and confirm that theavailable balance of the settlement account is sufficient to fund theinitiated payment transactions (e.g., as specified within the elementsof reconciled transaction data 318). Further, reconciliation module 312may perform operations that store reconciliation data 322 within aportion of transaction database 152 associated with settlement request228, e.g., within data records 310, and additionally, or alternatively,perform any of the exemplary processes described herein to storereconciliation data 322 within the cloud-based repository accessible topayer indirect clearing system 122 or to payer direct clearing system142.

In other instances, not illustrated in FIG. 3A, reconciliation module312 may determine that the aggregate transaction value exceeds theavailable balance of the settlement account and as such, that theavailable balance is insufficient to fund each of the initiated paymenttransactions. Based on tis determination, reconciliation module 312 mayaccess the elements of correlated transaction data 222 (e.g., whichcharacterize corresponding ones of the initiated payment transactions),and modify a transaction parameter value within one or more the accessedelements to reduce the aggregate transaction value for consistency withthe available balance. For example, reconciliation module 312 may reducethe transaction amount characterizing a particular one of the initiatedpayment transactions (e.g., within a corresponding element of correlatedtransaction data 222), or may delay a transaction date or time for anadditional one of the initiated payment transactions (e.g., any maydelete a corresponding one of the accessed elements from correlatedtransaction data 222.

Further (not illustrated in FIG. 3A), reconciliation module 312 maypackage the modified elements of element of correlated transaction data222 into corresponding portions of reconciled transaction data 318.Reconciliation module 312 may also generate additional elements ofreconciliation data 322 that, for example, identify the aggregate valueof the payment transactions (e.g., prior to modification), and/or areduced aggregate value of the modified payment transactions andfurther, identify the modification applied to the one or more elementsof correlated transaction data 222 (e.g., that resulted in the reducedaggregate value).

Referring back to FIG. 3A, direct settlement module 320 may receivereconciled transaction data 318, and may perform operations that processeach element of reconciled transaction data 318 and generate acorresponding element of legacy transaction data 326 suitable forsubmission to and processing by transaction processing system 112. Forexample, each element of reconciled transaction data 318 may bestructured in accordance with the ISO 20022™ standard data-interchangeformat and as such, may include not only payment instruction informationthat specifies corresponding values of transaction parameters, but alsocorresponding elements of rich remittance transaction data.

As illustrated in FIG. 3A, direct settlement module 320 may accessmapping data 148, and extract legacy mapping data that maps ortransforms one or more elements of data structured in accordance the ISO20022™ standard data-interchange format to corresponding data elementsof data structured a legacy data-interchange format associated with bytransaction processing system 112. For example, direct settlement module320 may access an element 323 of reconciled transaction data 318, andextract payment instruction information 208 and rich transactionremittance data 210, each of which characterize the payment transactionthat satisfies the outstanding $7,5000.00 invoice. In some instances,legacy mapping data may indicate an inability of transaction processingsystem 112 to process rich transaction remittance data 210, and based onan application of legacy mapping data 221 to portions of paymentinstruction information 208, indirect settlement module 220 may generatecorresponding an element 328 of legacy transaction data 326 structuredin accordance with the legacy data-interchange format.

Direct settlement module 320 may also perform operations that packageelement 328 into a corresponding portion of legacy transaction data 326,and may perform similar operations that process each additional elementof reconciled transaction data 318 and generate a corresponding elementof legacy transaction data 326 structured in accordance with the legacydata-interchange format. Direct settlement module 320 may also package,into a corresponding portion of legacy transaction data 326 (e.g., intoa header portion, etc.), additional information that, among otherthings, identifies payer direct clearing system 142 (e.g., an InternetProtocol (IP) address) and/or executed transaction engine 304 (e.g., anapplication cryptogram, such as a hash value, random number,cryptographic key, etc.).

In some instances, direct settlement module 320 may further process eachelement of legacy transaction data 326, including element 328, to accessan identifier of a source account (e.g., the account number, etc., orthe payer’s deposit account at the payer financial institution), and toreplace that accessed identifier with a corresponding identifier of thesettlement account of payer indirect clearing system 122 (e.g., aportion of an actual or tokenized account number). Additionally, oralternatively, one or more of the elements of legacy transaction data326 may aggregated, or “netted,” prior to settlement, or may be combinedwith other legacy transaction data, e.g., in a batch settlement process.Further, although not depicted in FIG. 3A, direct settlement module 320may also perform operations that access account database 150, and modifyaccount balance data 316 to reflect a debit consistent with theaggregated transaction amount across all of the initiated paymenttransactions characterized by legacy transaction data 326.

As illustrated in FIG. 3A, direct settlement module 320 may performoperations that cause payer direct clearing system 142 to transmitlegacy transaction data 326, including element 328 that characterizesthe payment transaction associated with the outstanding $7,5000.00invoice, across network 120 to transaction processing system 112 (e.g.,as elements of request data). A secure, programmatic interfacemaintained by transaction processing system 112, such as an API, mayreceive and route legacy transaction data 326 to one or more applicationmodules that, when executed by the one or more processors, performoperations that validate legacy transaction data 326 and that settleeach of the initiated payment transactions in accordance with theelements of legacy transaction data 326, e.g., alone or in conjunctionwithin other computing systems operating within environment 100.

In some instances, by settling the initiated payment transactions,transaction processing system 112 may perform operations that executeeach of the initiated payment transactions in accordance with theelements of legacy transaction data 326. Further, and as describedherein, the secure programmatic interface maintained by transactionprocessing system 112, e.g., the API, may be inaccessible to payerindirect clearing system 122 or to any of the application programsexecuted by payer indirect clearing system.

Referring to FIG. 3B, and during the settlement and execution process,transaction processing system 112 may generate settlement report 330that identifies the payment transaction submitted for settlement (e.g.,via a corresponding one of the correlation identifiers) and a status ofthe payment transactions during the settlement process (e.g.,successfully settled, rejected, etc.). For example, and for the paymenttransaction associated with the outstanding $7,500.00 invoice from payer103 to the merchant, an element 332 of settlement report 330 may includecorrelation identifier 224 and report data 334 indicative of thesuccessful settlement of the payment transaction and the transfer of the$7,500.00 from the settlement account of payer indirect clearing system122 to the destination account of the merchant (e.g., as specifiedwithin element 328 of legacy transaction data 326).

In some instances, transaction processing system 112 may performoperations that transmit settlement report 330 across network 120 topayer direct clearing system 142, e.g., via a secure programmaticinterface, such as API 336. As illustrated in FIG. 3B, API 336 mayreceive settlement report 330, and route settlement report 330 back toreconciliation module 312, which may perform further reconciliationprocessing based on the correlated transaction data 222 andreconciliation data 322 (e.g., as maintained within data records 310 oftransaction database 152).

By way of example, and based on portions of settlement report 330,reconciliation module 312 may perform operations that confirm asuccessful (or alternatively, unsuccessful) settlement of each of thepayment transactions submitted to transaction processing system 112,e.g., as specified within correlated transaction data 222 and/orreconciliation data 322. Further, reconciliation module 312 may alsoperform operations that confirm an aggregated transaction value of thesettled transactions corresponds to the aggregated transaction value ofthe submitted payment transactions (e.g., as debited from the settlementaccount of payer indirect clearing system 122). In an event thatreconciliation module 312 were to detect an unsuccessfully settled oneof the submitted payment transactions, or an inconsistency between thesubmitted and settled payment transactions, reconciliation module 312may modify a portion of reconciliation data 322 to reflect the detectedinconsistency.

Further, in some instances, reconciliation module 312 may performoperations that store settlement report 330 within a portion oftransaction database 152 associated with settlement request 228, e.g.,within data records 310 (or additionally, or alternatively, within theone or more accessible, cloud-based data repositories described herein).Reconciliation module 312 may also provide settlement report 330 as aninput to a status module 336. In some instances, status module 336 mayprocess portions of correlated transaction data 222, reconciliation data322, and settlement report 330 to generate elements of status data 338,which summarize each of the payment transaction submitted forsettlement, and identify a reconciliation and a settlement status foreach of the submitted payment transactions.

By way of example, and for each of the submitted payment transactions,status module 336 may extract a corresponding one of the correlationidentifiers from settlement report 330. Status module 336 may alsoaccess data records 310 within transaction database 152 (e.g., which areassociated with settlement request 228), and for each of the extractedcorrelation identifiers, obtain a corresponding element of correlatedtransaction data 222 (e.g., that summarizes the corresponding paymenttransaction), a corresponding element of settlement report 330 (e.g.,that characterizes a settlement status of the corresponding paymenttransaction), and a corresponding element of reconciliation data 322(e.g., that identifies an outcome of the reconciliation process for thecorresponding payment transaction). Further, and for each of thesubmitted payment transactions, status module 336 may generate acorresponding element of status data 338 that includes the extractedcorrelation identifier and all, or a portion of, each of the extractedelements of correlated transaction data 222, settlement report 330,and/or reconciliation data 322.

For example, and for the particular payment transaction involving theoutstanding invoice for $7,500.00, status module 336 may generate anelement 340 of status data 338 that include, but is not limited to:correlation identifier 224; payment summary data 342 (e.g., thatincludes transaction parameter values extracted from correlatedtransaction data 222), settlement status data 344 (e.g., that includesinformation characterizing a successful settlement of the paymenttransaction and transfer of the $7,500.00 to the destination account ofthe merchant, as extracted from settlement report 330 ), andreconciliation status data 346 (e.g., that includes informationcharacterizing a successful reconciliation of the $7,500.00 paymentagainst the balance available within the settlement account of payerindirect clearing system 122, as extracted from reconciliation data322). Further, status module 336 may perform any of the exemplaryprocesses described herein to generate an additional element of statusdata 338 for each of the submitted payment transactions. As illustratedin FIG. 3B, status module 336 may provide status data 338 as an input toa block generation module 348, which may be executed by the one or moreprocessors of payer direct clearing system 142.

Executed block generation module 348 may receive status data 338, andmay access cryptographic library 146, e.g., as maintained within datarepository 144. In some instances, block generation module 348 mayperform operations that extract, from cryptographic library 146: (i)cryptographic data 350 that includes a private cryptographic keyassociated with payer direct clearing system 142 and a public keycertificate 358 of payer direct clearing system 142, which includes acorresponding public cryptographic key; and (ii) cryptographic data 352that includes a public key certificate 360 of payer indirect clearingsystem 122, which includes a corresponding public cryptographic key.

Block generation module 348 may perform operations that encrypt each ofthe elements of status data 338 using the public cryptographic key ofpayer indirect clearing system 122 (e.g., as extracted from public keycertificate 360), and may generate corresponding elements of encryptedstatus data 354. In some instances, block generation module 348 mayapply a digital signature 356 to the elements of encrypted status data354 based on the private cryptographic key of payer direct clearingsystem 142 (e.g., as extracted from cryptographic data 350). Further,and as illustrated in FIG. 3B, block generation module 348 may packageencrypted status data 354, digital signature 356, public key certificate358 of payer direct clearing system 142, and public key certificate 360of payer indirect clearing system 122 into corresponding portions of arecordation request 364.

In some instances, digital signature 356 and public key certificate 358may collectively represent data access control information 362 thatenables one or more computing systems within environment 100, such aspayer indirect clearing system 122, to establish an integrity andauthenticity of encrypted status data 354. Further, the inclusion ofpublic key certificate 360 within recordation request 364 may enablepayer indirect clearing system 122 to identify encrypted data capable ofdecryption using a corresponding private cryptographic key. Asillustrated in FIG. 3B, block generation module 348 may performoperations that cause payer direct clearing system 142 to broadcastrecordation request 364 across network 120 to each of peer systems 160,including peer system 162.

Peer system 162 may perform any of the exemplary, consensus-basedprocesses described herein to validate recordation request 364 and topackage all, or a portion, of recordation request 364 into a new ledgerblock. Through one or more of the consensus-based processes describedherein, peer system 162 may generate a latest, longest version of thepermissioned distributed ledger, e.g., an update to distributed ledger280, that includes the newly generated ledger blocks, and broadcast theupdated distributed ledger to payer indirect clearing system 122, payerdirect clearing system 142, additional ones of peer system 160, and toother computing systems and devices that participate in the permissioneddistributed-ledger network operating within environment 100, e.g., forstorage within a corresponding data repository.

For example, as illustrated in FIG. 3B, one or more of peer system 160,including peer system 162, may generate an updated distributed ledger380 that include a new ledger block 370 appended to one or more priorledger blocks, such as prior ledger block 272. A payload portion 371 ofnew ledger block 370 may include, among other things, encrypted statusdata 354, data access control information 362 (e.g., which itselfincludes digital signature 356 and public key certificate 358 of payerdirect clearing system 142), and public key certificate 360 of payerindirect clearing system 122. New ledger block 370 may also include adigital signature 372 applied to payload 371, e.g., using acorresponding private cryptographic key of peer system 162, and a hashvalue 374 computed based on an application of any appropriate hashalgorithm to payload 371 and digital signature 372, either alone or inconjunction with a corresponding public cryptographic key 278 of peersystem 162.

In some instances, and as described herein, the elements of paymentsummary data, settlement status data, and reconciliation status datathat characterize each of payment transactions within new ledger block370, and within updated distributed ledger 380, may include actualvalues of corresponding transaction parameters (e.g., within the paymentsummary data), actual status data characterizing the position thepayment transaction within the indirect settlement processes describedherein (e.g., within the settlement status data), or actualreconciliation data characterizing an outcome of the reconciliationprocess for the payment transaction (e.g., within the reconciliationstatus data). In other instances, and consistent with the disclosedexemplary embodiments, one or more of these elements of payment summarydata and settlement status data may instead include pointer data thatidentifies a storage location of an appropriate data element within acloud-based repository to accessible to payer indirect clearing system122, e.g., across network 120 via the secure programmatic interface.

In some examples, described herein, payer direct clearing system 142 mayreceive a settlement request, e.g., settlement request 228 of FIG. 2A,that characterizes one or more payment transactions initiated by devicesin communication with payer indirect clearing system 122. As payerdirect clearing system 142 may be associated with a direct participantin one or more transaction processing networks capable of settling eachof the initiated payment transactions, payer direct clearing system 142may maintain a settlement account for payer indirect clearing system122, and may perform operations that on behalf of payer indirectclearing system 122, clear these initiated payment transactions againstfunds maintained in the settlement account and submit correspondingpayment instructions to computing systems associated with the one ormore transaction processing networks for settlement.

Although payer direct clearing system 142 may receive a settlementreport characterizing a settlement status of each of the paymenttransactions after submission of the corresponding payment instructionsto the one or more transaction processing networks, current limitationson the processing cycle of these transactions processing networks, andof the direct participants in these transaction processing networks, maydelay the provisioning of payment summary and reconciliation data topayer indirect clearing system 122 by several additional business days.While these delays may pose inconveniences to the customers of thefinancial institution that operates payer indirect clearing system 122,the pending and unreconciled status of these payment transactions atpayer indirect clearing system 122 can increase a susceptibility ofpayer indirect clearing system 122 to instances of fraudulent activity,and further increase a computational workload necessary to detect andcorrect and impact of these fraudulent activities during an eventualreconciliation process.

In some exemplary embodiments, one or more participants in apermissioned, distributed-ledger network, such as payer indirectclearing system 122 and payer direct clearing system 142 of FIG. 1 , mayperform operations that record certain elements of payment summary,reconciliation status, and settlement status data within acryptographically secure and permissioned distributed ledger at discretetemporal positions within the payment clearance, reconciliation, andsettlement process. For instance, and as described herein, payer directclearing system 142 may perform operations that record, within one ormore ledger blocks of the permissioned distributed ledger, datasummarizing a settlement and subsequent reconciliation of one or morepayment transactions submitted by payer indirect clearing system 122. Byencrypting the elements of payment, reconciliation, or settlement datausing a public cryptographic key of payer indirect clearing system 122,certain of these exemplary processes may enable payer indirect clearingsystem 122 to access, in real time, the encrypted elements of paymentsummary, reconciliation status, or settlement status data, and toperform further operations and reconcile one or more initiated paymenttransactions, and post these reconciled transactions to customeraccounts, without the delays associated with conventional transactionprocessing and further, without the increased potential for fraudulentactivity associated with these delays.

Referring to FIG. 4 , payer indirect clearing system 122 may receiveupdated distributed ledger 380, which includes ledger blocks 370 and272, and may perform operations that store updated distributed ledger380 within a corresponding portion of data repository 124, e.g., toreplace prior distributed ledgers 170 and 280. In some instances, andwhen executed by the one or more processors of payer indirect clearingsystem 122, validation module 216 may access cryptographic library 126and extract public key certificate 262 and a corresponding privatecryptographic key 402 associated with, or assigned to, payer indirectclearing system 122.

Validation module 216 may access updated distributed ledger 380, andparse each of the ledger blocks to identify one or more of the ledgerbocks that record public key certificate 262 (e.g., in additional to anyrecorded encrypted data or data access control information) and as such,are amenable to decryption and processing by payer indirect clearingsystem 122. By way of example, and as illustrated in FIG. 4 , validationmodule 216 may determine that ledger block 370 includes public keycertificate 262 (and the underlying public cryptographic key), and mayaccess encrypted status data 354 and data access control information362, along with digital signature 372, hash value 374, and publiccryptographic key 278 associated with peer system 162, which generatedledger block 370.

In some instances, validation module 216 may perform operations thatverify an integrity of ledger block 370 based on digital signature 372and hash value 374. By way of example, validation module 216 may performoperations that validate digital signature 372 using publiccryptographic key 278, and may further compute a local hash value basedon an application of an appropriate hash function to encrypted statusdata 354, data access control information 362, and digital signature372. If validation module 216 were unable to validate digital signature372, or were to detect an inconsistency between hash value 374 and thelocally computed hash value, validation module 216 may decline to verifythe integrity of ledger block 272, and may await a receipt of anadditional version of the distributed ledger from one of peer systems160.

Alternatively, and in response to a validation of digital signature 372and a determined consistency between hash value 374 and the locallycomputed hash value, validation module 216 may verify the integrity ofledger block 370, and may perform additional operations that verify anintegrity of encrypted status data 354 based on portions of data accesscontrol information 362. For example, validation module 216 may obtainpublic key certificate 358 of payer direct clearing system 142 from dataaccess control information 362, and further, may extract the publiccryptographic key of payer direct clearing system 142 from public keycertificate 358. In some instances, validation module 216 may performoperations that validate digital signature 356, e.g., as included withindata access control information 362, using the extracted public keycertificate of payer direct clearing system 142.

If validation module 216 were unable to validate digital signature 356,validation module 216 may decline to verify the integrity of encryptedstatus data 354, and may await a receipt of an additional version of thedistributed ledger from one of peer systems 160. Alternatively, inresponse to a successful validation of digital signature 356, validationmodule 216 may verify the integrity of encrypted status data 354, andmay perform operations that decrypt all or a portion of encrypted statusdata 354 using private cryptographic key 402, and provide decryptedsummary data, e.g., status data 338 of FIG. 3B, as an input to areconciliation module 404 of executed transaction engine 214.

As described herein, each element of status data 338 is associated with,and corresponds to, one of the payment transactions submitted by payerindirect clearing system 122, and cleared and settled by payer directclearing system 142 using any of the exemplary processes describedherein. For example, status data 338 may include an element 340 thatidentifies and characterizes the particular payment transactioninvolving the outstanding invoice for $7,500.00, and element 340 mayinclude, among other things: correlation identifier 224; payment summarydata 342 (e.g., that includes transaction parameter values extractedfrom correlated transaction data 222); settlement status data 344 (e.g.,that includes information characterizing a successful settlement of thepayment transaction and transfer of the $7,500.00 to the destinationaccount of the merchant, as extracted from settlement report 330); andreconciliation status data 346 (e.g., that includes informationcharacterizing a successful reconciliation of the $7,500.00 paymentagainst the balance available within the settlement account of payerindirect clearing system 122, as extracted from reconciliation data322). Further, although not depicted in FIG. 4 , status data 338 mayinclude additional data elements that characterize each of the submittedadditional payment transactions.

Reconciliation module 404 may also perform operations that accesstransaction database 130 (e.g., as maintained within data repository124), and obtain elements of correlated transaction data 222 thatidentify and characterize each of the initiated payment transactionssubmitted to payer direct clearing system 142. In other instances, notillustrated in FIG. 4 , reconciliation module may access pointer datamaintained within transaction database 130, and obtain the elements ofcorrelated transaction data 222 from a file location within one or morecloud-based data repositories associated with the accessed pointer data.

For example, element 226 of correlated transaction data 222 may identifyand characterize the payment transaction involving the outstandinginvoice for $7,500.00, and may include correlation identifier 224 andtransaction data element 206 (e.g., that includes payment instructioninformation 208 and rich transaction remittance data 210). Although notdepicted in FIG. 4 , correlated transaction data 222 may includeadditional data elements that characterize each of the additionalpayment transactions submitted by payer indirect clearing system 122,and cleared and settled by payer direct clearing system 142 using any ofthe exemplary processes described herein.

In some instances, reconciliation module 404 may perform operations thatreconcile each of the payment transactions based on correspondingelements of status data 338 and correlated transaction data 222. By wayof example, and for the particular payment transaction involving theoutstanding invoice for $7,500.00, reconciliation module 404 may parseelement 340 of status data 338 to confirm that payer direct clearingsystem 142 successfully cleared and settled the particular paymenttransaction for an amount (e.g., $7,500.00) consistent with paymentinstruction information 208, and that the one or more transactionprocessing networks successfully transferred the $7,500.00 to theaccount of the merchant, e.g., payment instruction information 208.

Reconciliation module 404 may generate an element 406 of reconciliationdata indicative of the successful and completed settlement of theparticular payment transaction, and associate reconciliation dataelement 406 with element 226 of correlated transaction data 222 withintransaction database 130 (not illustrated in FIG. 4 ). In someinstances, reconciliation module may also provide payment summary data342 and reconciliation data element 406 as inputs to indirect settlementmodule 220 of executed transaction engine 214, which may access accountdatabase 128, and identify a data record 408 that characterizes thefinancial services account of the payer (i.e., the source accountspecified within payment summary data 342), and a data record 410identifying a settlement account associated payer indirect clearingsystem 122, which funds indirect settlement processing by payer directclearing system 142.

As illustrated in FIG. 4 , indirect settlement module 220 may performoperations that modify data record 408 to include debit data 412indicative of a debit of $7,500.00 for the financial services account ofpayer 103, and that modify data record 410 to include credit data 414indicative of a credit of $7,500.00 for the settlement account, whichmay be swept and transferred to the direct participant that operatespayer direct clearing system 142. Further, although not illustrated inFIG. 4 , indirect settlement module 220 may perform any of theseexemplary processes to reconcile each of the additional paymenttransactions submitted to payer direct clearing system 142 based oncorresponding pairs of elements of status data 338 and correlatedtransaction data 222.

In some exemplary embodiments, as described herein, one or morecomputing systems associated with payer 103, such as, but not limitedto, payer indirect clearing system 122 and payer direct clearing system142, may participate in a permissioned, distributed-ledger network,e.g., one or more of peer systems 160. Through any of the exemplaryconsensus-based processes described herein, payer direct clearing system142 may immutably record, within one or more ledger blocks of apermissioned distributed ledger, encrypted status data characterizing areconciliation and settlement status of one or more payment transactionssubmitted by for settlement and clearance by payer indirect clearingsystem 122. As a participant in the permissioned distributed-ledgernetwork, payer indirect clearing system 122 may be configured to accessthe permissioned distributed ledger, and based on a selective decryptionof that encrypted status data, payer indirect clearing system 122 mayperform any of the exemplary processes described herein to reconcileeach of the submitted payment transactions without the temporal delayand resulting increased potential for fraudulent activity thatcharacterizes many conventional indirect settlement protocols thatleverage existing payment rails.

The disclosed exemplary embodiments are, however, not limited topermissioned, distributed-ledger networks that include direct andindirect clearing systems operated by or associated with payer 103 orthe payer financial institution. For example, and as described herein,payer indirect clearing system 122 may submit, within settlement request228, an element of correlated transaction data 222 that characterizesthe particular payment transaction that satisfies an outstanding$7,500.00 invoice issued by a merchant. The element of correlatedtransaction data 222 may identify, among other things, a destinationaccount associated with the payment transaction, which may correspond toa deposit account held by a merchant at a corresponding financialinstitution, e.g., a “payee” financial institution. In some instances,the payee financial institution may also represent an indirectparticipant in the one or more transaction processing networks describedherein, and as an indirect participant in these transaction processingnetworks, the payee financial institution relies on an additional,direct participant to generate and broadcast reporting datacharacterizing the clearance and settlement of the particular paymenttransaction prior to transferring funds into the deposit account held bythe merchant.

As described below in reference to FIG. 5 , the permissioned,distributed-ledger network may also include one or more additionalparticipants associated with the merchant or the payee financialinstitution, such as, but not limited to, a payee indirect clearingsystem 522 and a payee direct clearing system 542. By way of example,and as described below in reference to FIGS. 6A and 6B, payee directclearing system 542 may receive settlement report data that identifiesand characterizes one or more payment transactions settled by the one ormore transaction processing networks, e.g., based on data exchanged withtransaction processing system 112. At least a portion of these settledpayment transactions involve transfers of funds to an account maintainedby the payee financial institution, and in some instances, payee directclearing system 542 may perform operations that record certainselectively encrypted elements of payment summary, reconciliation,and/or status data that characterize the portion of the settled paymenttransactions within a cryptographically secure and permissioned,distributed ledger accessible to payee indirect clearing system 522.

In some instances, and as a participant in the permissioned,distributed-ledger network, payee indirect clearing system 522 mayaccess the permissioned distributed ledger and decrypt the selectivelyencrypted elements of the payment summary, reconciliation, and/or statusdata (e.g., using a corresponding private key). Further, and based onthe decrypted elements of the payment summary, reconciliation, and/orstatus data, payee indirect clearing system 522 may perform operationsthat reconcile each of these payment transactions, and credit funds tothe associated deposit or financial services accounts, in real-time andwithout the delays associated with conventional transaction processingnetworks and the increased potential for fraudulent activity associatedwith these delays.

Referring to FIG. 5 , an additional portion of exemplary computingenvironment 100 may include one or more computing systems associatedwith a transaction processing network, such as transaction processingsystem 112, payee indirect clearing system 522, payee direct clearingsystem 542, and one or more peer systems 160, such as peer system 162.Further, each of transaction processing system 112, payee indirectclearing system 522, payee direct clearing system 542, and peer systems160, including peer system 162, may be interconnected through anycombination of communications networks, such as network 120.

As described above for transaction processing system 112 and peersystems 162, each of payee indirect clearing system 522 and payee directclearing system 542 may represent a computing system that includes oneor more servers (e.g., one or more processors) and tangible,non-transitory memory devices storing executable code and applicationmodules. The servers may each include one or more processor-basedcomputing devices, which may be configured to execute portions of thestored code or application modules to perform operations consistent withthe disclosed embodiments, including operations consistent with theexemplary process described herein that manage, monitor, and reconcileinitiated exchanges of data using cryptographically secure andpermissioned distributed ledgers. Further, in some examples, each ofpayee indirect clearing system 522 and payee direct clearing system 542may each include a communications interface coupled to the one or moreprocessors for accommodating wired or wireless communication acrossnetwork 120 with any of the additional network-connected systems ordevices described, e.g., a transceiver device. In other instances, oneor more of payee indirect clearing system 522 and payee direct clearingsystem 542 may correspond to a distributed system that includescomputing components distributed across one or more networks, such asnetwork 120, or other networks, such as those provided or maintained bycloud-service providers. Further, one or more of payee indirect clearingsystem 522 and payee direct clearing system 542 can be incorporated intoa single computing system, as described herein.

To facilitate a performance of one or more of the exemplary processesdescribed herein, payee indirect clearing system 522 may maintain,within the one or more tangible, non-transitory memories, a datarepository 524 that includes, but is not limited to, a cryptographiclibrary 526, an account database 528, and a transaction database 530. Insome instances, cryptographic library 526 may include an asymmetriccryptographic key pair associated with, generated by, or assigned topayee indirect clearing system 522 (e.g., a private cryptographic keyand a corresponding public cryptographic key), along with public keycertificates associated with one or more additional computing systemswithin environment 100, such as, but not limited to, payee directclearing system 542 or other computing systems associated with oroperated by a financial institution associated with one or more payeesinvolved in corresponding payment transactions.

Account database 528 may include structured or unstructured data recordsthat identify and characterize one or more financial services accountsissued by the payer financial institution to the merchant and othercustomers, and in some instances, transaction database 530 may includestructured or unstructured data records that identify and characterizepayment transactions involving the financial services accounts held bymerchant and other customers. Further, data repository 524 may alsoinclude a local copy of a latest, longest version of a permissioneddistributed ledger, such as, but not limited to, updated distributedledger 380 that includes ledger blocks 272 and 370.

Further, and to facilitate a performance of these exemplary processes,payee direct clearing system 542 may maintain, within the one or moretangible, non-transitory memories, a data repository 544 that includes,but is not limited to, a cryptographic library 546, an account database548, and a transaction database 550. In some instances, cryptographiclibrary 546 may include an asymmetric cryptographic key pair associatedwith, generated by, or assigned to payee direct clearing system 542(e.g., a private cryptographic key and a corresponding publiccryptographic key), along with public key certificates associated withone or more additional computing systems within environment 100, suchas, but not limited to, payee indirect clearing system 522 or othercomputing systems associated with or operated by a financial institutionassociated with one or more payees involved in corresponding paymenttransactions.

Account database 548 may include structured or unstructured data recordsthat identify and characterize one or more financial services accountsissued to one or more customers of payee direct clearing system 542,such as a direct settlement account of payee direct clearing system 542and an indirect settlement account maintained on behalf of payeeindirect clearing system 522. Further, transaction database 550 mayinclude structured or unstructured data records that identify andcharacterize one or more exchanges of data (e.g., payment transactions)submitted for settlement and clearance using any of the exemplaryprocesses described herein, or additional exchanges of data settled andcleared using any of the exemplary processes described herein, e.g.,portions of payment data routed from payee indirect clearing system 522to payee direct clearing system 522. Data repository 544 may alsoinclude a local copy of a latest, longest version of a permissioneddistributed ledger, such as updated distributed ledger 380 that includesledger blocks 272 and 370.

Referring to FIG. 6A, and through an implementation of any of theexemplary transaction settlement processes described herein, transactionprocessing system 112 may generate settlement report 602 that identifiesone or more settled payment transactions involving accounts maintainedby payee direct clearing system 542 on behalf of various customers, suchas, but not limited to, a settlement account associated with the payeefinancial institution. In some instances, each element of settlementreport 602 may correspond to a respective one of the settled paymenttransactions, and may include a unique identifier assigned to thatrespective payment transaction, along with status data characterizing astatus of the respective payment transaction during the settlementprocess (e.g., successfully settled, rejected, etc.). In otherinstances, settlement report 602 may specify that one or more subsets ofthe payment transactions were aggregated or “netted” prior tosettlement.

For example, and for the particular payment transaction associated withthe outstanding $7,500.00 invoice from payer 103 to the merchant,settlement report 602 may include correlation identifier 224 and reportdata 604 indicative of the successful settlement of the paymenttransaction and the transfer of the $7,500.00 from the settlementaccount of payer indirect clearing system 122 (e.g., as maintained bypayer direct clearing system 142 of FIG. 1 ) to the indirect settlementaccount of payee indirect clearing system 522 (e.g., as maintained bypayee direct clearing system 542). In some instances, transactionprocessing system 112 may perform operations that transmit settlementreport 602 across network 120 to payee direct clearing system 542, e.g.,via a secure programmatic interface, such as an API 606. As illustratedin FIG. 6A, API 606 may receive and route settlement report 602 to areconciliation and settlement module 608, which upon execution by theone or more processors of payee direct clearing system 542, performsreconciliation processing based on locally maintained elements ofaccount data and portions of settlement report 602.

By way of example, and based on portions of settlement report 602,reconciliation and settlement module 608 may perform operations thatconfirm a successful (or alternatively, unsuccessful) settlement of eachof the payment transaction associated with the outstanding $7,500.00invoice. In some instances, and respective to a successful settlement,reconciliation and settlement module 608 may access account database548, and identify one or more data records that include account data 610characterizing, among other things, a current balance of the directsettlement account of payee direct clearing system 542, which collectssettled funds prior to disbursement to various specified destinationaccounts. Based on a determination that current balance of the directsettlement account exceeds $7,500.00 (e.g., the transaction amount ofthe settled transaction), reconciliation and settlement module 608 maymodify a portion of account data 610 to include a debit 612 indicativeof the settled payment transaction that satisfies the outstanding$7,500.00 invoice.

Further, reconciliation and settlement module 608 may also access one ormore additional data records of account database 548, and identifyadditional account data 614 that characterizes an account balance of theindirect settlement account of payee indirect clearing system 522, whichcollects funds derived from payment transactions settled by payee directclearing system 542 on behalf of payee indirect clearing system 522.Reconciliation and settlement module 608 may perform operations thatmodify a portion of account data 614 to include a credit 616 indicativeof the settled payment transaction that satisfies the outstanding$7,500.00 invoice. Additionally, in some instances, reconciliation andsettlement module 608 generate one or more elements of reconciliationdata 618, which characterize the exemplary reconciliation processesdescribed herein, and specify that the $7,500.00 associated with thesettled payment transaction identified in settlement report 602 is readyfor transfer to the destination account at payee indirect clearingsystem 522.

In some instances, illustrated in FIG. 6A, reconciliation and settlementmodule 608 may perform operations that store correlation identifier 224and report data 604, which identify and characterize the now-settledpayment transaction involving the $7,500.00 invoice, within one or moredata records of transaction database 550, along with the generatedelements of reconciliation data 618 (not illustrated in FIG. 6A). Inother instances, reconciliation and settlement module 608 may performoperations that store portions of correlation identifier 224, reportdata 604, and reconciliation data 618 within one or more of thecloud-based data repositories described herein, and maintain pointerdata indicative of the corresponding file locations within the one ormore data records of transaction database 550.

Further, reconciliation and settlement module 608 may also providesettlement report 602 and reconciliation data 618 as inputs to a statusmodule 620, which, when executed by the one or more processors of payeedirect clearing system 542, generates elements of status data 626summarizing the settled payment transaction (e.g., the paymenttransaction involving the $7,500.00 invoice) and elements of datacharacterizing the settlement and reconciliation status of that paymenttransaction. For example, status module 620 may parse settlement report602, and extract correlation identifier 224 and report data 604. Basedon a portion of report data 604, transaction summary module 620 maygenerate elements of payment summary data 622 that specifies values ofparameters that characterize the now-settled payment transaction (e.g.,a transaction value of $7,500.00, an identifier of the merchant or thedestination account of the merchant, etc.) and settlement status data624 that characterizes the successful settlement of the paymenttransaction. As illustrated in FIG. 6A, status module 620 may packagecorrelation identifier 224, payment summary data 622, settlement statusdata 624, and reconciliation data 618 into corresponding potions ofstatus data 626.

In some instances, payment summary data 622 may be structured as acorresponding payment instruction characterized by a standard,data-interchange format, such as the ISO 20022™ standarddata-interchange format described herein. Further, although notillustrated in FIG. 6A, status module 620 may perform any of theexemplary processes described herein to generate discrete portions ofsummary data for additional, or alternate, payment transactions settledby transaction processing system 112 and specified within settlementreport 602.

Status module 620 may provide summary data 626 as an input to a blockgeneration module 628, which may be executed by the one or moreprocessors of payee direct clearing system 542. In some instances, andupon receipt of summary data 626, executed block generation module 628may access cryptographic library 546, e.g., as maintained within datarepository 544, and extract, from cryptographic library 546: (i)cryptographic data 630 that includes a private cryptographic keyassociated with payee direct clearing system 542 and a public keycertificate 632 of payee direct clearing system 542, which includes acorresponding public cryptographic key; and (ii) cryptographic data 634that includes a public key certificate 636 of payee indirect clearingsystem 522, which includes a corresponding public cryptographic key. Insome instances, each of the public key certificates may be generated bya corresponding certificate authority operating within environment 100,e.g., a certificate authority associated with the permissioneddistributed-ledger network described herein.

Block generation module 628 may perform operations that encrypt each ofthe elements of summary data 626 using the public cryptographic key ofpayer indirect clearing system 522 (e.g., as extracted from public keycertificate 636), and may generate corresponding elements of encryptedstatus data 638. In some instances, block generation module 628 mayapply a digital signature 640 to the elements of encrypted status data638 based on the private cryptographic key of payer direct clearingsystem 542 (e.g., as extracted from cryptographic data 630). Further,and as illustrated in FIG. 6A, block generation module 628 may packageencrypted status data 638, digital signature 640, public key certificate632 of payee direct clearing system 142, and public key certificate 636of payee indirect clearing system 522 into corresponding portions of arecordation request 644.

In some instances, digital signature 640 and public key certificate 632may collectively represent data access control information 642 thatenables one or more computing systems within environment 100, such aspayee indirect clearing system 522, to establish an integrity andauthenticity of encrypted status data 638. Further, the inclusion ofpublic key certificate 636 within recordation request 644 may enablepayee indirect clearing system 522 to identify encrypted data capable ofdecryption using a corresponding private cryptographic key. Asillustrated in FIG. 6A, block generation module 628 may performoperations that cause payee direct clearing system 542 to broadcastrecordation request 644 across network 120 to each of peer systems 160,including peer system 162.

By way of example, peer system 162 may perform any of the exemplary,consensus-based processes described herein to validate recordationrequest 644 and to package all, or a portion, of recordation request 644into a new ledger block 646. Through the implementation of one or moreof the consensus-based processes described herein, peer system 162 maygenerate a latest, longest version of the permissioned distributedledger, e.g., an update to distributed ledger 380, that includes thenewly generated ledger blocks, and broadcast the updated distributedledger to payee indirect clearing system 522, payee direct clearingsystem 542, additional ones of peer system 160, and to other computingsystems and devices that participate in the permissioneddistributed-ledger network operating within environment 100.

For example, as illustrated in FIG. 6A, peer system 162 may generate anupdated distributed ledger 652 that include new ledger block 646appended to one or more prior ledger blocks, such as prior ledger blocks370 and 272. A payload portion 647 of new ledger block 646 may include,among other things, encrypted status data 638, data access controlinformation 642 (e.g., which itself includes digital signature 640 andpublic key certificate 632 of payee direct clearing system 542), andpublic key certificate 636 of payer indirect clearing system 522. Newledger block 370 may also include a digital signature 648 applied topayload 647, e.g., using a corresponding private cryptographic key ofpeer system 162, and a hash value 650 computed based on an applicationof any appropriate hash algorithm to payload 647 and digital signature648, either alone or in conjunction with a corresponding publiccryptographic key 278 of peer system 162.

In some instances, and as described herein, the elements of paymentsummary data, settlement status data, and reconciliation status datathat characterize each of payment transactions within new ledger block646, and within updated distributed ledger 652, may include actualvalues of corresponding transaction parameters (e.g., within the paymentsummary data), actual status data characterizing the position thepayment transaction within the indirect settlement processes describedherein (e.g., within the settlement status data), or actualreconciliation data characterizing an outcome of the reconciliationprocess for the payment transaction (e.g., within the reconciliationstatus data). In other instances, and consistent with the disclosedexemplary embodiments, one or more of these elements of payment summarydata, settlement status data, and reconciliation status data may insteadinclude pointer data that identifies a storage location of anappropriate data element within a cloud-based repository to accessibleto payee indirect clearing system 522 and payee direct clearing system542.

Referring to FIG. 6B, payee indirect clearing system 522 may receiveupdated distributed ledger 652, which includes ledger blocks 646, 370,and 272, and may perform operations that store updated distributedledger 652 within a corresponding portion of data repository 524, e.g.,to replace prior distributed ledgers 170, 280 and/or 380. In someinstances, and when executed by the one or more processors of payeeindirect clearing system 522, a validation module 662 may accesscryptographic library 526 and extract public key certificate 636 and acorresponding private cryptographic key 664 associated with, or assignedto, payee indirect clearing system 522.

Validation module 662 may access updated distributed ledger 652, andparse each of the ledger blocks to identify one or more of the ledgerbocks that record public key certificate 636 (e.g., in additional to anyrecorded encrypted data or data access control information) and as such,are amenable to decryption and processing by payee indirect clearingsystem 522. By way of example, and as illustrated in FIG. 6C, validationmodule 662 may determine that ledger block 646 includes public keycertificate 636 (and the underlying public cryptographic key), and mayaccess encrypted status data 638 and data access control information642, along with digital signature 648, hash value 650, and publiccryptographic key 278 associated with peer system 162, which generatedledger block 646.

In some instances, validation module 662 may perform operations thatverify an integrity of ledger block 646 based on digital signature 648and hash value 650. By way of example, validation module 662 may performoperations that validate digital signature 648 using publiccryptographic key 278, and may further compute a local hash value basedon an application of an appropriate hash function to encrypted statusdata 638, data access control information 642, and digital signature 648(and in some instances, public key certificate 636). If validationmodule 662 were unable to validate digital signature 648, or were todetect an inconsistency between hash value 650 and the locally computedhash value, validation module 662 may decline to verify the integrity ofledger block 646, and may await a receipt of an additional version ofthe distributed ledger from one of peer systems 160.

Alternatively, and in response to a validation of digital signature 648and a determined consistency between hash value 650 and the locallycomputed hash value, validation module 662 may verify the integrity ofledger block 646, and may perform additional operations that verify anintegrity of encrypted status data 638 based on portions of data accesscontrol information 642. For example, validation module 662 may obtainpublic key certificate 632 of payee direct clearing system 542 from dataaccess control information 642, and further, may extract the publiccryptographic key of payee direct clearing system 542 from public keycertificate 632. In some instances, validation module 662 may performoperations that validate digital signature 640, e.g., as included withindata access control information 642, using the extracted publiccryptographic key of payer direct clearing system 542.

If validation module 662 were unable to validate digital signature 640,validation module 662 may decline to verify the integrity of encryptedstatus data 638, and may await a receipt of an additional version of thedistributed ledger from one of peer systems 160. Alternatively, inresponse to a successful validation of digital signature 640, validationmodule 662 may verify the integrity of encrypted status data 638, andmay perform operations that decrypt all or a portion of encrypted statusdata 638 using private cryptographic key 664 and provide decryptedsummary data, e.g., summary data 626 of FIG. 6A, as an input to areconciliation and settlement module 666 of payee indirect clearingsystem 522.

As described herein, summary data 626 may be associated with, andcorresponds to, a particular one of the payment transactions submittedby payee indirect clearing system 522, and cleared and settled by payeedirect clearing system 542 using any of the exemplary processesdescribed herein. For example, status data 626 may identify andcharacterize the particular payment transaction involving theoutstanding invoice for $7,500.00, and may include, among other things,correlation identifier 224, payment summary data 622 (e.g., thatincludes transaction parameter values extracted from settlement report602, such as the $7,500.00 transaction amount, an identifier of thedestination account, etc.), settlement status data 624 (e.g., thatincludes information characterizing a successful settlement of thepayment transaction and transfer of the $7,500.00 to the destinationaccount of the merchant, as extracted from settlement report 602), andreconciliation data 618 (e.g., that includes information characterizinga successful reconciliation of the $7,500.00 payment against the balanceavailable within the settlement account of payee indirect clearingsystem 522). Although, not depicted in FIGS. 6A and 6B, status data 626may include additional data elements that characterize additionalpayment transactions submitted by payee indirect clearing system 522,and cleared and settled by payee direct clearing system 542 using any ofthe exemplary processes described herein.

Reconciliation and settlement module 666 may also perform operationsthat access one or more data records of account database 528, andidentify account data 668 that characterizes an account balance of thedeposit account held by the merchant, e.g., the destination accountspecified within payment summary data 622, and account data 670 thatcharacterized an indirect settlement account of payee indirect clearingsystem 522 that receives proceeds from, or that funds, the indirectsettlement processing by payee direct clearing system 542.Reconciliation and settlement module 666 may perform operations thatmodify a portion of account data 668 to include a credit data 672indicative of a credit of $7,500.00, which corresponds to the settledpayment that satisfies the outstanding $7,500.00 invoice. Further,reconciliation and settlement module 666 may also perform operationsthat modifies account data 670 to include debit data indicative of adebit of $7,500.00, which facilitates the transfer of funds to themerchant’s account.

FIG. 7 is a flowchart of an exemplary process 700 for executing andreconciling cryptographically secure exchanges of data usingpermissioned distributed ledger, in accordance with the disclosedembodiments. In some instances, one or more network-connected computingsystems operating within environment 100, such a payer indirect clearingsystem 122 may perform the steps of exemplary process 700 that include,among other things, receiving elements of transaction datacharacterizing discrete transactions initiated at a client device, andbased on a validation of the transaction data elements, submittingportions of the transaction data elements to an additional computingsystem operating within environment 100, such as payer direct clearingsystem 142, for indirect clearance and settlement, and recordingselective encrypted data characterizing a status of the initiatedtransaction within the indirect clearance and settlement process withinone or more ledger blocks of permissioned distributed ledger.

Referring to FIG. 7 , payer indirect clearing system 122 may receivetransaction data generated by one or more network-connected devicesoperating within environment 100, such as payer device 102 of FIG. 1(e.g., in step 702). In some instances, the received transaction datamay include elements of transaction data, each of which may identify andcharacterize a corresponding payment transaction between payer 103 andone or more corresponding counterparties.

As described herein, the discrete elements of transaction data may begenerated by an application program executed by one or more processorsof payer device 102, e.g., executed payment application 202 of FIG. 2A.Further, executed payment application 202 may package, intocorresponding portions of transaction data 204 (e.g., into a headerportion, etc.), additional information that, among other things,identifies a payer that operates payer device 102 (e.g., a logincredential or digital identifier of payer 103 of FIG. 1 ), payer device102 (e.g., an Internet Protocol (IP) address) and/or executed paymentapplication 202 (e.g., an application cryptogram, such as a hash value,random number, cryptographic key, etc.).

In some instances, each of the transaction data elements may bestructured in accordance with a standardized data-interchange format,such as the ISO 20022™ standard data-interchange format describedherein, and may include payment instruction information specifyingparameter values that characterize a corresponding one of the paymenttransactions and rich transaction remittance data associated with thecorresponding payment transaction. Examples of the payment instructioninformation include, but are not limited to, a transaction type, atransaction value, a transaction date or time, identifiers of the payerand corresponding payee, and identifiers of corresponding payer andpayee accounts, and examples of the rich transaction remittance datainclude, but are not limited to, an electronic copy of one or more pagesof the invoice or the packing list, an electronic copy of acorresponding purchase order, or payment advice, as described herein.

Payer indirect clearing system 122 may, for example, perform any of theexemplary processes described herein that validate the receivedtransaction data based on, among other things, the information thatidentifies payer 103, payer device 102, and additionally, oralternatively, executed application program 202 (e.g., in step 704). Ifpayer indirect clearing system 122 were unable to validate transactiondata 204 (e.g., step 704; NO), payer indirect clearing system 122 mayperform operations that discard the received transaction data, and thatto generate and transmit an error message to payer device 102 (e.g., instep 706). Exemplary process 700 may then pass back to step 702, andpayer indirect clearing system 122 may await additional elements oftransaction data generated by payer device 102.

Alternatively, if payer indirect clearing system 122 validates thereceived transaction data (e.g., step 704; YES), payer indirect clearingsystem 122 may perform any of the exemplary processes described hereinto assign a unique alphanumeric identifier, e.g., a correlationidentifier, to each element of the validated transaction data (e.g., instep 708). The assigned correlation identifiers may be characterized bya predetermined length or a predetermined structure, and examples of thecorrelation identifiers include, but are not limited to, a random numberor a hash value generated based on portions of corresponding elements ofthe validated transaction data. In some instances, payer indirectclearing system 122 may perform additional operations that package eachelement of the validated transaction data and the assigned correlationidentifier into an element of correlated transaction data (e.g., also instep 708).

In some instances, payer indirect clearing system 122 may also performoperations that generate a settlement request for submission to acomputing system operated by, or associated with, a direct participantin the one or more transaction processing networks described herein,e.g., payer direct clearing system 142 of FIG. 1 (e.g., in step 710). Byway of example, and in step 710, payer indirect clearing system 122 mayperform any of the exemplary processes described herein to package allor a portion of the correlated transaction data 222 into the settlementrequest, along with additional information that identifies payerindirect clearing system 122 (e.g., an IP address, a unique digitalidentifier, such as a cryptogram or hash value, etc.) or one or morefinancial services accounts maintained on behalf of payer indirectclearing system 122 by payer direct clearing system 142.

Payer indirect clearing system 122 may perform operations that apply adigital signature to the settlement request, e.g., using a privatecryptographic key, and may perform operations that transmit thedigitally signed settlement request to payer direct clearing system 142(e.g., in step 712). In some instances, payer direct clearing system 142may perform any of the exemplary processes described herein to clear andreconcile each of the payment transactions specified within thesettlement request, and to submit data characterizing these cleared andreconciled payment transaction to the one or more transaction processingnetworks, e.g., for settlement in accordance with reconciled transactionparameter values. Further, and as described herein, payer directclearing system 142 may perform additional consensus-based operationsthat record selectively encrypted elements of payment summary data,reconciliation status data, and/or settlement status data within one ormore ledger blocks of a permissioned distributed ledger, whichfacilitate an implementation of time-efficient and cryptographicallysecure process for reconciling the settled payment transactions at payerindirect clearing system 122.

Referring back to FIG. 7 , payer indirect clearing system 122 mayperform any of the exemplary processes described herein to generateelements of status data characterizing each of the submitted paymenttransaction (e.g., in step 714). By way of example, and for each of thesubmitted payment transactions, a corresponding element of the statusdata may include the assigned correlation identifier (e.g., as extractedfrom a corresponding element of the correlated transaction data),payment summary data (e.g., derived from payment instructionsinformation and rich transaction remittance data included within thecorresponding element of the correlated transaction data), andsettlement status data (e.g., specifying that payer indirect clearingsystem 122 submitted the settlement request to payer direct clearingsystem 142).

In some instances, payer indirect clearing system 122 may performoperations that selectively encrypt the generated status data, e.g.,using a public cryptographic key associated with payer direct clearingsystem 142 (e.g., in step 716). Further, payer indirect clearing system122 may perform any of the exemplary processes described herein torecord the selected encrypted status data within an additional ledgerblock of a permissioned, distributed ledger (e.g., in step 718). By wayof example, in step 718, payer indirect clearing system 122 may generatea recordation request that includes the selectively encrypted statusdata, a digital signature applied to the selectively encrypted statusdata using a private cryptographic key of payer indirect clearing system122, and a public key certificate of payer indirect clearing system 122.Further, in step 718, payer indirect clearing system 122 may broadcastthe recordation request to one or more peer systems within thepermissioned, distributed-ledger network, e.g., peer systems 160 of FIG.1 .

Peer systems 160, including peer system 162, may perform any of theexemplary, consensus-based processes described herein to validate therecordation request and to package all, or a portion, of the recordationrequest into a new ledger block. Through the implementation of one ormore of the consensus-based processes described herein, peer systems 160may generate a latest, longest version of the permissioned distributedledger that includes the newly generated ledger block, and broadcast theupdated distributed ledger to payer indirect clearing system 122, payerdirect clearing system 142, additional ones of peer system 160, and toother computing systems and devices that participate in the permissioneddistributed-ledger network operating within environment 100, e.g., forstorage within a corresponding data repository. Exemplary process 700 isthen complete in step 720.

FIG. 8 is a flowchart of an exemplary process 800 for executing andreconciling cryptographically secure exchanges of data usingpermissioned distributed ledger, in accordance with the disclosedembodiments. In some instances, one or more network-connected computingsystems operating within environment 100, such a payer direct clearingsystem 142 may perform the steps of exemplary process 800, whichinclude, among other things, receive a settlement request from anindirect participant in on one or more transaction processing networks,and based on a validation of the settlement request, perform operationsthat, on behalf of the indirect participant, clear and reconcile paymenttransactions specified within the settlement request and submitformatted payment instructions associated with the specified paymenttransactions to the one or more transaction processing networks forsettlement. Further, payer direct clearing system 142 may performadditional steps of exemplary process 800 to record selectivelyencrypted elements of payment summary data, reconciliation status data,and/or settlement status data within one or more ledger blocks of apermissioned distributed ledger, which facilitates an implementation oftime-efficient and cryptographically secure process for reconciling thesettled payment transactions at payer indirect clearing system 122.

Referring to FIG. 8 , payer direct clearing system 142 may receive asettlement request from a computing system associated with an indirectparticipant in the one or more transaction processing networks, such aspayer indirect clearing system 122 of FIG. 1 (e.g., in step 802). Insome instances, and as described herein, the received settlement requestmay include discrete elements of transaction data that identify andcharacterize one or more payment transactions initiated at anetwork-connected device within environment 100, such as payer device102 of FIG. 1 , along with information that that identifies payerindirect clearing system 122 (e.g., an IP address, a cryptogram, etc.),a settlement account of payer indirect clearing system 122 (e.g., anaccount number, etc.), or an application program executed by payerindirect clearing system 122 (e.g., a cryptogram, etc.).

Payer direct clearing system 142 may, for example, perform any of theexemplary processes described herein to validate the received settlementrequest based on, among other things, the information that identifiespayer indirect clearing system 122, the settlement account, or theexecuted application program (e.g., in step 704). If payer directclearing system 142 were unable to validate the settlement request(e.g., step 804; NO), payer direct clearing system 142 may discard thesettlement request, and may perform operations that generate andtransmit an error message (e.g., in step 806). Exemplary method 800 maythen pass back to step 802, and payer direct clearing system 142 mayawait additional settlement requests generated by payer indirectclearing system 122 and computing systems operated by other indirectparticipants in the one or more transaction processing networks.

Alternatively, if payer direct clearing system 142 were to validate thesettlement request (step 804; YES), payer direct clearing system 142 mayperform operations that reconcile the payment transactions specifiedwithin the settlement requests to against corresponding elements oflocally maintained account data (e.g., in step 808). By way of example,and in step 808, payer direct clearing system 142 may perform any of theexemplary processes described herein to verify an available balance in asettlement account of payer indirect clearing system 122 is equivalentto, or exceeds, an aggregated transaction value of the paymenttransactions submitted for settlement by payer indirect transactionsystem 122, e.g., as specified within the settlement request. Further,in step 808, payer direct clearing system 142 may also performoperations that generate, and store within the one or more tangible,non-transitory memories, elements of reconciliation data that, forexample, identify the available balance of the settlement account and/orthe aggregate value of the initiated payment transactions, and confirmthat the available balance of the settlement account is sufficient tofund the initiated payment transactions.

Payer direct clearing system 142 may also extract, from the settlementrequest, the transaction data elements identifying and characterizingeach of the payment transactions, and may perform any of the exemplaryprocesses described herein to process each of the extracted elements andgenerate a corresponding element of legacy transaction data (e.g., instep 810).

Payer direct clearing system 142 may submit the processed elements oflegacy transaction data to a computing system associated with, oroperated by, the one or more transaction processing networks, e.g.,transaction processing system 112 of FIG. 1 , for settlement (e.g., instep 812). As described herein, and during the settlement process,legacy transaction processing system 112 may generate elements of asettlement report that identify each of the payment transactionsubmitted for settlement (e.g., via a corresponding one of thecorrelation identifiers) and a status of the payment transaction duringthe settlement process (e.g., successfully settled, rejected, etc.). Insome instances, legacy transaction processing system 112 may performoperations that transmit the settlement report across network 120 topayer direct clearing system 142, which may receive the settlementreport data in step 814.

In some instances, payer direct clearing system 142 may perform any ofthe exemplary processes described herein to further reconcile thesubmitted payment transaction against corresponding elements of thesettlement report data, and to update the generated reconciliation databased on an outcome of these further reconciliation processes (e.g., instep 816). By way of example, and based on portions of the settlementreport, payer direct clearing system 142 may perform operations thatconfirm a successful (or alternatively, unsuccessful) settlement of eachof the initiated payment transaction submitted to transaction processingsystem 112, and confirm that an aggregated transaction value of thesettled transactions corresponds to the aggregated transaction value ofthe initiated payment transactions submitted for settlement (e.g., asdebited from the settlement account of payer indirect clearing system122). In an event that payer direct clearing system 142 were to detectan unsuccessfully settled one of the submitted payment transactions, oran inconsistency between the submitted and settled payment transactions,direct clearing system 142 may modify the generated reconciliation datato reflect the detected inconsistency (e.g., also in step 816).

Payer indirect clearing system 122 may perform any of the exemplaryprocesses described herein to generate discrete elements of status datathat characterize each of the settled payment transactions and further,a reconciliation and a settlement status of each of the submittedpayment transactions (e.g., in step 818). By way of example, and for acorresponding one of the submitted payment transactions: a correspondingelement of the status data may include the assigned correlationidentifier (e.g., as extracted from a corresponding element of theextracted transaction data); payment summary data (e.g., that summarizesthe corresponding payment transaction, as derived from paymentinstructions information and rich transaction remittance data includedwithin the corresponding element of the extracted transaction data);settlement status data (e.g., that characterizes a settlement status ofthe corresponding payment transaction); and reconciliation status data(e.g., that identifies an outcome of the reconciliation process for thecorresponding payment transaction).

In some instances, payer direct clearing system 142 may performoperations that selectively encrypt the generated status data, e.g.,using a public cryptographic key associated with payer indirect clearingsystem 122 (e.g., in step 820). Further, payer direct clearing system142 may perform any of the exemplary processes described herein torecord the selectively encrypted status data within an additional ledgerblock of a permissioned, distributed ledger (e.g., in step 720). By wayof example, in step 720, payer direct clearing system 142 may generate arecordation request that includes the selectively encrypted status data,elements of digital access control information (e.g., a public keycertificate of payer direct clearing system 142 and a digital signatureapplied to the selectively encrypted status data using a privatecryptographic key of payer direct clearing system 142), and a public keycertificate of payer indirect clearing system 122. Further, in step 822,payer indirect clearing system 122 may broadcast the recordation requestto one or more peer systems within the permissioned, distributed-ledgernetwork, e.g., peer systems 160 of FIG. 1 .

Peer systems 160, including peer system 162, may perform any of theexemplary, consensus-based processes described herein to validate therecordation request and to package all, or a portion, of the recordationrequest into a new ledger block. Through the implementation of one ormore of the consensus-based processes described herein, peer systems 160may generate a latest, longest version of the permissioned distributedledger that includes the newly generated ledger block, and broadcast theupdated distributed ledger to payer indirect clearing system 122, payerdirect clearing system 142, additional ones of peer system 160, and toother computing systems and devices that participate in the permissioneddistributed-ledger network operating within environment 100, e.g., forstorage within a corresponding data repository. Exemplary process 800 isthen complete in step 824.

FIG. 9 is a flowchart of an exemplary process 900 for reconcilingcryptographically secure exchanges of data using permissioneddistributed ledgers, in accordance with the disclosed embodiments. Insome instances, one or more network-connected computing systemsoperating within environment 100, such a payer indirect clearing system122 may perform the steps of exemplary process 900 that include, amongother things, receiving an updated distributed ledger that recordssummary data characterizing a clearance, reconciliation, or settlementstatus of one or more payment transactions, reconciling the one or morepayment transactions based on decrypted portions of the summary data.

Referring to FIG. 9 , payer indirect clearing system 122 may receive anupdated distributed ledger from one or more computing systems operatingwithin environment 100, e.g., peer system 162 of FIG. 1 (e.g., in step902). As described herein, the updated distributed ledger may record,within one or more ledger blocks, discrete elements of status dataselectively encrypted using a public cryptographic key of payer indirectclearing system 122, and the selectively encrypted elements of thestatus data may characterize a reconciliation and settlement status ofone or more payment transactions submitted by payer indirect clearingsystem 122 for indirect settlement by a direct participant in one ormore transaction processing networks, e.g., payer direct clearing system142 if FIG. 1 .

Payer indirect clearing system 122 may also access cryptographic datamaintained within one or more tangible, non-transitory memories, andextract a public key certificate and a corresponding privatecryptographic key associated with, or assigned to, payer indirectclearing system 122 (e.g., in step 904). Further, payer indirectclearing system 122 may parse the ledger blocks of the updateddistributed ledger to identify one of the ledger blocks that record thepublic key certificate of payer indirect clearing system 122 (e.g., inaddition to any recorded encrypted data or data access controlinformation) and as such, are amenable to decryption and processing bypayer indirect clearing system 122 (e.g., in step 906). By way ofexample, and in addition to the public key certificate of payer indirectclearing system 122, the identified ledger block may also includeencrypted status data and data access control information, along with adigital signature, a hash value, and public cryptographic key associatedwith peer system 162, which generated the identified ledger block.

In some instances, in step 908, payer indirect clearing system 122 mayperform any of the exemplary processes described herein to validate anintegrity of the identified ledger block and further, to validate anintegrity of the encrypted status data included within the identifiedledger block (e.g., in step 908). If payer indirect clearing system 122were unable to validate the integrity of either the identified ledgerblock or the encrypted status data (e.g., step 908; NO), exemplaryprocess 900 may pass back to step 902, and payer indirect clearingsystem 122 may await a receipt of an additional update to thedistributed ledger.

Alternatively, if payer indirect clearing system 122 were to validatethe integrity of the identified ledger block and the encrypted statusdata (e.g., step 908; YES), payer indirect clearing system 122 mayperform operations that decrypt the encrypted summary data using theprivate cryptographic key (e.g., in step 910). In some instances, eachelement of the decrypted status data is associated with, and correspondsto, one of the payment transactions submitted by payer indirect clearingsystem 122, and cleared and settled by payer direct clearing system 142using any of the exemplary processes described herein.

For example, and for a corresponding one of the submitted paymenttransactions, the decrypted status data may include, among other things:a corresponding correlation identifier; payment summary data (e.g., thatincludes transaction parameter values characterizing the correspondingone of the submitted payment transactions); settlement status data(e.g., that includes information characterizing a successful orunsuccessful settlement of the corresponding one of the submittedpayment transactions); and reconciliation status data (e.g., thatincludes information characterizing a reconciliation of thecorresponding one of the submitted payment transactions by payerindirect clearing system 122). Further, the decrypted status data mayinclude additional data elements that characterize each of theadditional payment transactions submitted by payer indirect clearingsystem 122, and cleared and settled by payer direct clearing system 142using any of the exemplary processes described herein.

In some instances, payer indirect clearing system 122 may perform any ofthe exemplary processes described herein to reconcile each of thesubmitted transactions based on corresponding portions of the decryptedstatus data (e.g., the payment summary data, the settlement status data,and the reconciliation status data for each of the submitted paymenttransactions) and elements of correlated transaction data locallymaintained by payer indirect clearing system 122 (e.g., in step 912). Byway of example, and for a particular one of the submitted paymenttransactions, payer indirect clearing system 122 may access acorresponding portion of the settlement status data within the decryptedstatus data and confirm that payer direct clearing system 142successfully cleared and settled the particular payment transaction inaccordance with consistent with payment summary data. Further, and basedon a corresponding portion of the payment summary data, payer indirectclearing system 122 may determine that the one or more transactionprocessing networks successfully transferred the funds consistent withthe transaction amount to the specified destination account.

Payer indirect clearing system 122 may also perform operations in step914 that generate an element of reconciliation data indicative of thesuccessful and completed settlement of the particular paymenttransaction, and store the generated element of reconciliation datawithin one or more tangible, non-transitory memories. Payer indirectclearing system 122 may perform any of these exemplary processes in step912 to reconcile each additional or alternate one of the submittedpayment transactions, as specified within the correlated transactiondata.

Referring back to FIG. 9 , payer indirect clearing system 122 mayperform additional operations that update account data associated withpayer 103, e.g., as identified within the payment summary data ofdecrypted status data, to reflect a credit or a debit associated witheach of the now-settled payment transactions (e.g., in step 914).Exemplary process 900 is then complete in step 916.

Exemplary embodiments of the subject matter and the functionaloperations described in this specification can be implemented in digitalelectronic circuitry, in tangibly-embodied computer software orfirmware, in computer hardware, including the structures disclosed inthis specification and their structural equivalents, or in combinationsof one or more of them. Further, exemplary embodiments of the subjectmatter described in this specification, including, but not limited to,payment application 202, APIs 212, 268, 302, 336, and 606, transactionengine 214, validation module 216, indirect settlement module 220,status module 234, block generation module 244, block generation module270, distributed consensus module 282, transaction engine 304,validation module 306, management module 308, reconciliation module 312,direct settlement module 320, status module 336, block generation module348, reconciliation module 404, reconciliation and settlement module608., status module 620, block generation module 628, validation module662, and reconciliation and settlement module 666, can be implemented asone or more computer programs, i.e., one or more modules of computerprogram instructions encoded on a tangible non-transitory programcarrier for execution by, or to control the operation of, a dataprocessing apparatus (or a computer system). Additionally, oralternatively, the program instructions can be encoded on anartificially-generated propagated signal, such as a machine-generatedelectrical, optical, or electromagnetic signal that is generated toencode information for transmission to suitable receiver apparatus forexecution by a data processing apparatus. The computer storage mediumcan be a machine-readable storage device, a machine-readable storagesubstrate, a random or serial access memory device, or a combination ofone or more of them.

The terms “apparatus,” “device,” and/or “system” refer to dataprocessing hardware and encompasses all kinds of apparatus, devices, andmachines for processing data, including by way of example a programmableprocessor, a computer, or multiple processors or computers. Theapparatus, device, and/or system can also be or further include specialpurpose logic circuitry, such as an FPGA (field programmable gate array)or an ASIC (application-specific integrated circuit). The apparatus,device, and/or system can optionally include, in addition to hardware,code that creates an execution environment for computer programs, suchas code that constitutes processor firmware, a protocol stack, adatabase management system, an operating system, or a combination of oneor more of them.

A computer program, which may also be referred to or described as aprogram, software, a software application, a module, a software module,a script, or code, can be written in any form of programming language,including compiled or interpreted languages, or declarative orprocedural languages, and it can be deployed in any form, including as astand-alone program or as a module, component, subroutine, or other unitsuitable for use in a computing environment. A computer program may, butneed not, correspond to a file in a file system. A program can be storedin a portion of a file that holds other programs or data, such as one ormore scripts stored in a markup language document, in a single filededicated to the program in question, or in multiple coordinated files,such as files that store one or more modules, sub-programs, or portionsof code. A computer program can be deployed for execution on onecomputer or on multiple computers that are located at one site ordistributed across multiple sites and interconnected by a communicationnetwork.

The processes and logic flows described in this specification can beperformed by one or more programmable computers executing one or morecomputer programs to perform functions by operating on input data andgenerating output. The processes and logic flows can also be performedby, and apparatus can also be implemented as, special purpose logiccircuitry, such as an FPGA (field programmable gate array) or an ASIC(application-specific integrated circuit).

Computers suitable for the execution of a computer program include, byway of example, general or special purpose microprocessors or both, orany other kind of central processing unit. For example, a centralprocessing unit will receive instructions and data from a read-onlymemory or a random access memory or both. The central processing mayalso for perform or execute instructions and may be operatively coupledone or more memory devices for storing instructions and data. Further,the computer will also include, or be operatively coupled to receivedata from or transfer data to, or both, one or more mass storage devicesfor storing data, such as magnetic, magneto-optical disks, or opticaldisks. However, the computer need not have such devices. Moreover, thecomputer can be embedded in another device, such as a mobile telephone,a personal digital assistant (PDA), a mobile audio or video player, agame console, a Global Positioning System (GPS) receiver, or a portablestorage device, such as a universal serial bus (USB) flash drive, toname just a few.

Computer-readable media suitable for storing computer programinstructions and data include all forms of non-volatile memory, mediaand memory devices, including by way of example semiconductor memorydevices, such as EPROM, EEPROM, and flash memory devices; magneticdisks, such as internal hard disks or removable disks; magneto-opticaldisks; and CD-ROM and DVD-ROM disks. The processor and the memory can besupplemented by, or incorporated in, special purpose logic circuitry.

To provide for interaction with a user, embodiments of the subjectmatter described in this specification can be implemented on a computerhaving a display device, such as a CRT (cathode ray tube) or LCD (liquidcrystal display) monitor, for displaying information to the user and akeyboard and a pointing device, such as a mouse or a trackball, by whichthe user can provide input to the computer. Other kinds of devices canbe used to provide for interaction with a user as well; for example,feedback provided to the user can be any form of sensory feedback, suchas visual feedback, auditory feedback, or tactile feedback; and inputfrom the user can be received in any form, including acoustic, speech,or tactile input. In addition, a computer can interact with a user bysending documents to and receiving documents from a device that is usedby the user; for example, by sending web pages to a web browser on auser’s device in response to requests received from the web browser.

Implementations of the subject matter described in this specificationcan be implemented in a computing system that includes a back-endcomponent, such as a data server, or that includes a middlewarecomponent, such as an application server, or that includes a front-endcomponent, such as a client computer having a graphical user interfaceor a Web browser through which a user can interact with animplementation of the subject matter described in this specification, orany combination of one or more such back-end, middleware, or front-endcomponents. The components of the system can be interconnected by anyform or medium of digital data communication, such as a communicationnetwork. Examples of communication networks include a local area network(LAN) and a wide area network (WAN), such as the Internet.

The computing system can include clients and servers. A client andserver are generally remote from each other and typically interactthrough a communication network. The relationship of client and serverarises by virtue of computer programs running on the respectivecomputers and having a client-server relationship to each other. In someimplementations, a server transmits data, such as an HTML page, to auser device, such as for purposes of displaying data to and receivinguser input from a user interacting with the user device, which acts as aclient. Data generated at the user device, such as a result of the userinteraction, can be received from the user device at the server.

While this specification contains many specifics, these should not beconstrued as limitations on the scope of the invention or of what may beclaimed, but rather as descriptions of features specific to particularembodiments of the invention. Certain features that are described inthis specification in the context of separate embodiments may also beimplemented in combination in a single embodiment. Conversely, variousfeatures that are described in the context of a single embodiment mayalso be implemented in multiple embodiments separately or in anysuitable sub-combination. Moreover, although features may be describedabove as acting in certain combinations and even initially claimed assuch, one or more features from a claimed combination may in some casesbe excised from the combination, and the claimed combination may bedirected to a sub-combination or variation of a sub-combination.

Similarly, while operations are depicted in the drawings in a particularorder, this should not be understood as requiring that such operationsbe performed in the particular order shown or in sequential order, orthat all illustrated operations be performed, to achieve desirableresults. In certain circumstances, multitasking and parallel processingmay be advantageous. Moreover, the separation of various systemcomponents in the embodiments described above should not be understoodas requiring such separation in all embodiments, and it should beunderstood that the described program components and systems maygenerally be integrated together in a single software product orpackaged into multiple software products.

In each instance where an HTML file is mentioned, other file types orformats may be substituted. For instance, an HTML file may be replacedby an XML, JSON, plain text, or other types of files. Moreover, where atable or hash table is mentioned, other data structures (such asspreadsheets, relational databases, or structured files) may be used.

While this specification contains many specifics, these should not beconstrued as limitations, but rather as descriptions of featuresspecific to particular implementations. Certain features that aredescribed in this specification in the context of separateimplementations may also be implemented in combination in a singleimplementation. Conversely, various features that are described in thecontext of a single implementation may also be implemented in multipleimplementations separately or in any suitable sub-combination. Moreover,although features may be described above as acting in certaincombinations and even initially claimed as such, one or more featuresfrom a claimed combination may in some cases be excised from thecombination, and the claimed combination may be directed to asub-combination or variation of a sub-combination.

Similarly, while operations are depicted in the drawings in a particularorder, this should not be understood as requiring that such operationsbe performed in the particular order shown or in sequential order, orthat all illustrated operations be performed, to achieve desirableresults. In certain circumstances, multitasking and parallel processingmay be advantageous. Moreover, the separation of various systemcomponents in the implementations described above should not beunderstood as requiring such separation in all implementations, and itshould be understood that the described program components and systemsmay generally be integrated together in a single software product orpackaged into multiple software products.

Various exemplary embodiments have been described herein with referenceto the accompanying drawings. It will, however, be evident that variousmodifications and changes may be made thereto, and additionalembodiments may be implemented, without departing from the broader scopeof the disclosed embodiments as set forth in the claims that follow. Itis intended, therefore, that this disclosure and the examples herein beconsidered as exemplary only, with a true scope and spirit of thedisclosed embodiments being indicated by the following listing ofexemplary claims.

Additionally, and in this application, the use of the singular includesthe plural unless specifically stated otherwise. In this application,the use of “or” means “and/or” unless stated otherwise. Furthermore, theuse of the term “including,” as well as other forms such as “includes”and “included,” is not limiting. In addition, terms such as “element” or“component” encompass both elements and components comprising one unit,and elements and components that comprise more than one subunit, unlessspecifically stated otherwise. Additionally, the section headings usedherein are for organizational purposes only, and are not to be construedas limiting the described subject matter.

1-20. (canceled)
 21. An apparatus, comprising: a communicationsinterface; a memory storing instructions; and at least one processorcoupled to the communications interface and the memory, the at least oneprocessor being configured to execute the instructions to: transmit, viathe communications interface, first information characterizing a dataexchange to a first computing system, the first information beingstructured in accordance with a first format and the first computingsystem being configured to transmit request data that requests anexecution of the data exchange to a second computing system, the requestdata being structured in accordance with a second format and comprisinga portion of the first information, and the second computing systembeing configured to execute the data exchange in accordance with atleast the portion of the first information; obtain, from at least oneelement of a distributed ledger, encrypted second information thatcharacterizes the executed data exchange; and decrypt the encryptedsecond information and perform operations based on the first informationand at least a portion of the decrypted second information.
 22. Theapparatus of claim 21, wherein the operations comprise reconciling theexecuted data exchange based on the first information and at least theportion of the decrypted second information.
 23. The apparatus of claim21, wherein: the first information comprises first parameter values ofthe data exchange, and the request data includes at least a subset ofthe first parameter values; and the second computing system is furtherconfigured to execute the data exchange in accordance with at least thesubset of the first parameter values.
 24. The apparatus of claim 23,wherein: the first information further comprises additional contentassociated with the data exchange; and the first computing system isfurther configured to: apply mapping data to the first parameter valuesand to the additional content, the mapping data comprising informationthat maps the first format to the second format; based on theapplication of the mapping data to the additional content, determinethat the second computing system is incapable of processing theadditional content; and generate the request data based on theapplication of the mapping data to the first parameter values.
 25. Theapparatus of claim 23, wherein: the decrypted second informationcomprises second parameter values that characterize the executed dataexchange; and the at least one processor is further configured toexecute the instructions to reconcile the executed data exchange basedon the first parameter values against corresponding ones of the secondparameter values.
 26. The apparatus of claim 21, wherein: the firstformat corresponds to a standardized data-interchange format; the secondformat corresponds to a legacy data-interchange format associated with alegacy processing network; the second computing system is associatedwith the legacy processing network; and the first computing system isfurther configured to generate the request data based on an applicationof mapping data to the portion of the first information, the mappingdata comprising information that maps the standardized data-interchangeformat to the legacy data-interchange format.
 27. The apparatus of claim21, wherein the first computing system is further configured to transmitthe request data to the second computing system via a programmaticinterface, the programmatic interface being associated with the secondcomputing system, and the programmatic interface being inaccessible tothe apparatus via the communications interface.
 28. The apparatus ofclaim 21, wherein the at least one processor is further configured toexecute the instructions to receive the first information from a devicevia the communications interface, the first information being generatedby an application program executed at the device, and the data exchangebeing initiated at the device.
 29. The apparatus of claim 21, whereinthe at least one processor is further configured to execute theinstructions to: load, from the memory, the least one element of thedistributed ledger and cryptographic data that includes a privatecryptographic key associated with the apparatus; and decrypt theencrypted second information using the private cryptographic key. 30.The apparatus of claim 21, wherein the first computing system is furtherconfigured to: generate the second information and encrypt the secondtransaction information using a public cryptographic key of theapparatus; and transmit the encrypted second information to a peercomputing system, the peer computing system being configured to performadditional operations that record the encrypted second informationwithin the at least one element of the distributed ledger.
 31. Theapparatus of claim 21, wherein the at least one processor is furtherconfigured to execute the instructions to: perform additional operationsthat apply a digital signature to at least the first information;generate additional request data that requests the execution of the dataexchange by the second computing system, the additional request datacomprising the first transaction information and the digital signature;and transmit the additional request data to the first computing systemvia the communications interface, the first computing system beingconfigured to validate the additional request data and to obtain thefirst information from the additional request data.
 32. Acomputer-implemented method, comprising: transmitting, using at leastone processor, first information characterizing a data exchange to afirst computing system, the first information being structured inaccordance with a first format and the first computing system beingconfigured to transmit request data that requests an execution of thedata exchange to a second computing system, the request data beingstructured in accordance with a second format and comprising a portionof the first information, and the second computing system beingconfigured to execute the data exchange in accordance with at least theportion of the first information; obtaining, using the at least oneprocessor, and from at least one element of a distributed ledger,encrypted second information that characterizes the executed dataexchange; and using the at least one processor, decrypting the encryptedsecond information and performing operations based on the firstinformation and at least a portion of the decrypted second information.33. An apparatus, comprising: a communications interface; a memorystoring instructions; and at least one processor coupled to thecommunications interface and the memory, the at least one processorbeing configured to execute the instructions to: receive, via thecommunications interface, first information characterizing a dataexchange from a first computing system, the first information beingstructured in accordance with a first format; based on the firstinformation, transmit, to a second computing system via thecommunications interface, request data that requests an execution of thedata exchange by the second computing system, the request datacomprising at least a portion of the first information and beingstructured in accordance with a second format, and the second computingsystem being configured to execute the data exchange in accordance withat least the portion of the first information; encrypt secondinformation that characterizes the executed data exchange and performoperations that record the encrypted second information within at leastone element of a distributed ledger.
 34. The apparatus of claim 33,wherein: the first computing system is configured to receive the firstinformation from a device, the first information being generated by anapplication program executed at the device, and the data exchange beinginitiated at the device the first information comprises first parametervalues of the data exchange, and the request data further comprises atleast a subset of the first parameter values; and the second computingsystem is further configured to execute the data exchange in accordancewith at least the subset of the first parameter values.
 35. Theapparatus of claim 34, wherein: the first information comprisesadditional content associated with the data exchange; the at least oneprocessor is further configured to execute the instructions to: applymapping data to the first parameter values and to the additionalcontent, the mapping data comprising information that maps the firstformat to the second format; based on the application of the mappingdata to the additional content, determine that the second computingsystem is incapable of processing the additional content; and generatethe request data based on the application of the mapping data to thefirst parameter values.
 36. The apparatus of claim 34, wherein: thesecond information comprises second parameter values that characterizethe executed data exchange; and the at least one processor is furtherconfigured to execute the instructions to generate the secondinformation and encrypt the second information using a publiccryptographic key associated with the distributed ledger.
 37. Theapparatus of claim 33, wherein the at least one processor is furtherconfigured to execute the instructions to transmit the encrypted secondinformation to a peer computing system, the peer computing system beingconfigured to perform additional operations that record the encryptedsecond information within the at least one element of the distributedledger.
 38. The apparatus of claim 33, wherein the at least oneprocessor is further configured to execute the instructions to transmit,via the communications interface, the request data to the secondcomputing system through a programmatic interface associated with thesecond computing system, the programmatic interface being inaccessibleto the first computing system across a communications network.
 39. Theapparatus of claim 33, wherein the distributed ledger comprises apermissioned distributed ledger, the permissioned distributed ledgerbeing accessible to the apparatus and the first computing system. 40.The apparatus of claim 33, wherein the first computing system is furtherconfigured to: obtain the at least one element of the distributedledger; decrypt the encrypted second information using a privatecryptographic key associated with the distributed ledger; and performoperations that reconcile the executed data exchange based on the firstinformation and at least a portion of the decrypted second information.